Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 22 2月, 2011 2 次提交
  3. 31 1月, 2011 1 次提交
  5. 28 1月, 2011 6 次提交
    • A
      Don't pass "--xhtml" to hightlight in gitweb.perl script. · d2d434be
      由 Adam Tkac 提交于 
      The "--xhtml" option is supported only in highlight < 3.0. There is no option
to enforce (X)HTML output format compatible with both highlight < 3.0 and
highlight >= 3.0. However default output format is HTML so we don't need to
explicitly specify it.
Signed-off-by: NAdam Tkac <atkac@redhat.com>
Helped-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      d2d434be
    • J
      Merge branch 'maint' · 99e63ef2
      由 Junio C Hamano 提交于 
      * maint:
  rebase -i: clarify in-editor documentation of "exec"
  tests: sanitize more git environment variables
  fast-import: treat filemodify with empty tree as delete
  rebase: give a better error message for bogus branch
  rebase: use explicit "--" with checkout

Conflicts:
	t/t9300-fast-import.sh
      99e63ef2
    • 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. 25 1月, 2011 5 次提交
  11. 22 1月, 2011 2 次提交
    • J
      Subject: setup: officially support --work-tree without --git-dir · 4868b2ea
      由 Jonathan Nieder 提交于 
      The original intention of --work-tree was to allow people to work in a
subdirectory of their working tree that does not have an embedded .git
directory.  Because their working tree, which their $cwd was in, did not
have an embedded .git, they needed to use $GIT_DIR to specify where it is,
and because this meant there was no way to discover where the root level
of the working tree was, so we needed to add $GIT_WORK_TREE to tell git
where it was.

However, this facility has long been (mis)used by people's scripts to
start git from a working tree _with_ an embedded .git directory, let git
find .git directory, and then pretend as if an unrelated directory were
the associated working tree of the .git directory found by the discovery
process.  It happens to work in simple cases, and is not worth causing
"regression" to these scripts.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      4868b2ea
    • J
      Documentation: do not treat reset --keep as a special case · 8c0db6fd
      由 Jonathan Nieder 提交于 
      The current treatment of "git reset --keep" emphasizes how it
differs from --hard (treatment of local changes) and how it breaks
down into plumbing (git read-tree -m -u HEAD <commit> followed by git
update-ref HEAD <commit>).  This can discourage people from using
it, since it might seem to be a complex or niche option.

Better to emphasize what the --keep flag is intended for --- moving
the index and worktree from one commit to another, like "git checkout"
would --- so the reader can make a more informed decision about the
appropriate situations in which to use it.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      8c0db6fd
  13. 21 1月, 2011 1 次提交
    • B
      Correctly report corrupted objects · 25f3af3f
      由 Björn Steinbrink 提交于 
      The errno check added in commit 3ba7a065 "A loose object is not corrupt
if it cannot be read due to EMFILE" only checked for whether errno is
not ENOENT and thus incorrectly treated "no error" as an error
condition.

Because of that, it never reached the code path that would report that
the object is corrupted and instead caused funny errors like:

  fatal: failed to read object 333c4768ce595793fdab1ef3a036413e2a883853: Success

So we have to extend the check to cover the case in which the object
file was successfully read, but its contents are corrupted.
Reported-by: NWill Palmer <wmpalmer@gmail.com>
Signed-off-by: NBjörn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      25f3af3f
  15. 20 1月, 2011 15 次提交
  17. 19 1月, 2011 4 次提交
  19. 16 1月, 2011 1 次提交
  21. 14 1月, 2011 1 次提交