Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 17 2月, 2011 3 次提交
  3. 10 2月, 2011 2 次提交
  5. 28 1月, 2011 4 次提交
    • J
      rebase -i: clarify in-editor documentation of "exec" · 960ac5ff
      由 Jonathan Nieder 提交于 
      The hints in the current "instruction sheet" template look like so:

 # Rebase 3f142468..a1d7e01 onto 3f142468
 #
 # Commands:
 #  p, pick = use commit
 #  r, reword = use commit, but edit the commit message
 #  e, edit = use commit, but stop for amending
 #  s, squash = use commit, but meld into previous commit
 #  f, fixup = like "squash", but discard this commit's log message
 #  x <cmd>, exec <cmd> = Run a shell command <cmd>, and stop if it fails
 #
 # If you remove a line here THAT COMMIT WILL BE LOST.
 # However, if you remove everything, the rebase will be aborted.
 #

This does not make it clear that the format of each line is

	<insn> <commit id> <explanatory text that will be printed>

but the reader will probably infer that from the automatically
generated pick examples above it.

What about the "exec" instruction?  By analogy, I might imagine that
the format of that line is "exec <command> <explanatory text>", and
the "x <cmd>" hint does not address that question (at first I read it
as taking an argument <cmd> that is the name of a shell).  Meanwhile,
the mention of <cmd> makes the hints harder to scan as a table.

So remove the <cmd> and add some words to remind the reader that
"exec" runs a command named by the rest of the line.  To make room, it
is left to the manpage to explain that that command is run using
$SHELL and that nonzero status from that command will pause the
rebase.

Wording from Junio.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      960ac5ff
    • J
      tests: sanitize more git environment variables · a1231de0
      由 Jeff King 提交于 
      These variables should generally not be set in one's
environment, but they do get set by rebase, which means
doing an interactive rebase like:

  pick abcd1234 foo
  exec make test

will cause false negatives in the test suite.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a1231de0
    • J
      Merge branch 'jn/fast-import-empty-tree-removal' into maint · 5ce32581
      由 Junio C Hamano 提交于 
      * jn/fast-import-empty-tree-removal:
  fast-import: treat filemodify with empty tree as delete
      5ce32581
    • J
      fast-import: treat filemodify with empty tree as delete · 8fe533f6
      由 Jonathan Nieder 提交于 
      Normal git processes do not allow one to build a tree with an empty
subtree entry without trying hard at it.  This is in keeping with the
general UI philosophy: git tracks content, not empty directories.

v1.7.3-rc0~75^2 (2010-06-30) changed that by making it easy to include
an empty subtree in fast-import's active commit:

	M 040000 4b825dc642cb6eb9a060e54bf8d69288fbee4904 subdir

One can trigger this by reading an empty tree (for example, the tree
corresponding to an empty root commit) and trying to move it to a
subtree.  It is better and more closely analogous to 'git read-tree
--prefix' to treat such commands as requests to remove the subtree.
Noticed-by: NDavid Barr <david.barr@cordelta.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      8fe533f6
  7. 27 1月, 2011 2 次提交
    • J
      rebase: give a better error message for bogus branch · 4ac5356c
      由 Jeff King 提交于 
      When you give a non-existent branch to git-rebase, it spits
out the usage. This can be confusing, since you may
understand the usage just fine, but simply have made a
mistake in the branch name.

Before:

  $ git rebase origin bogus
  Usage: git rebase ...

After:

  $ git rebase origin bogus
  fatal: no such branch: bogus
  Usage: git rebase ...
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      4ac5356c
    • J
      rebase: use explicit "--" with checkout · 3b21a438
      由 Jeff King 提交于 
      In the case of a ref/pathname conflict, checkout will
already do the right thing and checkout the ref. However,
for a non-existant ref, this has two advantages:

  1. If a file with that pathname exists, rebase will
     refresh the file from the index and then rebase the
     current branch instead of producing an error.

  2. If no such file exists, the error message using an
     explicit "--" is better:

       # before
       $ git rebase -i origin bogus
       error: pathspec 'bogus' did not match any file(s) known to git.
       Could not checkout bogus

       # after
       $ git rebase -i origin bogus
       fatal: invalid reference: bogus
       Could not checkout bogus

The problems seem to be trigger-able only through "git
rebase -i", as regular git-rebase checks the validity of the
branch parameter as a ref very early on. However, it doesn't
hurt to be defensive.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      3b21a438
  9. 20 1月, 2011 12 次提交
  11. 13 1月, 2011 1 次提交
  13. 11 1月, 2011 7 次提交
  15. 09 1月, 2011 1 次提交
  17. 06 1月, 2011 1 次提交
  19. 05 1月, 2011 2 次提交
  21. 30 12月, 2010 1 次提交
  23. 29 12月, 2010 4 次提交