Skip to content

G
git

李少辉-开发者 / git
与 Fork 源项目一致

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 14 2月, 2008 1 次提交
    • J
      diff --relative: output paths as relative to the current subdirectory · cd676a51
      由 Junio C Hamano 提交于 
      This adds --relative option to the diff family.  When you start
from a subdirectory:

        $ git diff --relative

shows only the diff that is inside your current subdirectory,
and without $prefix part.  People who usually live in
subdirectories may like it.

There are a few things I should also mention about the change:

 - This works not just with diff but also works with the log
   family of commands, but the history pruning is not affected.

   In other words, if you go to a subdirectory, you can say:

        $ git log --relative -p

   but it will show the log message even for commits that do not
   touch the current directory.  You can limit it by giving
   pathspec yourself:

        $ git log --relative -p .

   This originally was not a conscious design choice, but we
   have a way to affect diff pathspec and pruning pathspec
   independently.  IOW "git log --full-diff -p ." tells it to
   prune history to commits that affect the current subdirectory
   but show the changes with full context.  I think it makes
   more sense to leave pruning independent from --relative than
   the obvious alternative of always pruning with the current
   subdirectory, which would break the symmetry.

 - Because this works also with the log family, you could
   format-patch a single change, limiting the effect to your
   subdirectory, like so:

        $ cd gitk-git
        $ git format-patch -1 --relative 911f1eb

   But because that is a special purpose usage, this option will
   never become the default, with or without repository or user
   preference configuration.  The risk of producing a partial
   patch and sending it out by mistake is too great if we did
   so.

 - This is inherently incompatible with --no-index, which is a
   bolted-on hack that does not have much to do with git
   itself.  I didn't bother checking and erroring out on the
   combined use of the options, but probably I should.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      cd676a51
  3. 05 2月, 2008 3 次提交
  5. 04 2月, 2008 12 次提交
  7. 03 2月, 2008 5 次提交
  9. 02 2月, 2008 4 次提交
    • J
      Sane use of test_expect_failure · 41ac414e
      由 Junio C Hamano 提交于 
      Originally, test_expect_failure was designed to be the opposite
of test_expect_success, but this was a bad decision.  Most tests
run a series of commands that leads to the single command that
needs to be tested, like this:

    test_expect_{success,failure} 'test title' '
	setup1 &&
        setup2 &&
        setup3 &&
        what is to be tested
    '

And expecting a failure exit from the whole sequence misses the
point of writing tests.  Your setup$N that are supposed to
succeed may have failed without even reaching what you are
trying to test.  The only valid use of test_expect_failure is to
check a trivial single command that is expected to fail, which
is a minority in tests of Porcelain-ish commands.

This large-ish patch rewrites all uses of test_expect_failure to
use test_expect_success and rewrites the condition of what is
tested, like this:

    test_expect_success 'test title' '
	setup1 &&
        setup2 &&
        setup3 &&
        ! this command should fail
    '

test_expect_failure is redefined to serve as a reminder that
that test *should* succeed but due to a known breakage in git it
currently does not pass.  So if git-foo command should create a
file 'bar' but you discovered a bug that it doesn't, you can
write a test like this:

    test_expect_failure 'git-foo should create bar' '
        rm -f bar &&
        git foo &&
        test -f bar
    '

This construct acts similar to test_expect_success, but instead
of reporting "ok/FAIL" like test_expect_success does, the
outcome is reported as "FIXED/still broken".
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      41ac414e
    • J
      Update stale documentation links from the main documentation. · 6ce8e44a
      由 Junio C Hamano 提交于 
      This could have been part of the 1.5.4 commit, but it isn't.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      6ce8e44a
    • J
      GIT 1.5.4 · c3c13529
      由 Junio C Hamano 提交于 
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c3c13529
    • J
      Fix "git checkout -b foo ':/substring'" · 7dc46429
      由 Junio C Hamano 提交于 
      Because ':/substring' extended SHA1 expression cannot take
postfix modifiers such as ^{tree} and ^{commit}, we would need
to do it in multiple steps.  With the patch, you can start a new
branch from a randomly-picked commit whose message has the named
string in it.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      7dc46429
  11. 01 2月, 2008 3 次提交
  13. 31 1月, 2008 5 次提交
  15. 30 1月, 2008 6 次提交
  17. 29 1月, 2008 1 次提交