Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 10 2月, 2011 2 次提交
  3. 11 1月, 2011 1 次提交
  5. 16 12月, 2010 5 次提交
  7. 03 12月, 2010 1 次提交
  9. 02 12月, 2010 1 次提交
    • J
      add: introduce add.ignoreerrors synonym for add.ignore-errors · 6b3020a2
      由 Jonathan Nieder 提交于 
      The "[add] ignore-errors" tweakable introduced by v1.5.6-rc0~30^2 (Add
a config option to ignore errors for git-add, 2008-05-12) does not
follow the usual convention for naming values in the git configuration
file.

What convention?  Glad you asked.

	The section name indicates the affected subsystem.

	The subsection name, if any, indicates which of
	an unbound set of things to set the value for.

	The variable name describes the effect of tweaking
	this knob.

	The section and variable names can be broken into
	words using bumpyCaps in documentation as a hint to
	the reader.  These word breaks are not significant
	at the level of code, since the section and variable
	names are not case sensitive.

The name "add.ignore-errors" includes a dash, meaning a naive
configuration file like

	[add]
		ignoreErrors

does not have any effect.  Avoid such confusion by renaming to the
more consistent add.ignoreErrors, but keep the old version for
backwards compatibility.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Acked-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      6b3020a2
  11. 28 7月, 2010 2 次提交
  13. 26 7月, 2010 5 次提交
  15. 08 7月, 2010 1 次提交
  17. 29 5月, 2010 2 次提交
  19. 05 5月, 2010 1 次提交
  21. 02 5月, 2010 2 次提交
  23. 24 4月, 2010 1 次提交
  25. 23 4月, 2010 5 次提交
  27. 22 4月, 2010 1 次提交
  29. 20 4月, 2010 2 次提交
  31. 19 4月, 2010 3 次提交
  33. 18 4月, 2010 4 次提交
    • W
      documentation: clarify direction of core.autocrlf · c308b9c2
      由 Will Palmer 提交于 
      The description for core.autocrlf refers to reads from / writes to
"the filesystem", the only use of this rather ambiguous term, which
technically could be referring to the git object database. (All other
mentions are part of phrases such as "..filesystems (like NFS)..").

Other sections, including the section on core.safecrlf, use the term
"work tree" for the same purpose as the term "the filesystem" is used in
the core.autocrlf section, so that seems like a good alternative, which
makes it clearer what direction the addition/removal of CR characters
occurs in.
Signed-off-by: NWill Palmer <wmpalmer@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c308b9c2
    • J
      diff: use large integers for diffstat calculations · 0974c117
      由 Jeff King 提交于 
      The diffstat "added" and "changed" fields generally store
line counts; however, for binary files, they store file
sizes. Since we store and print these values as ints, a
diffstat on a file larger than 2G can show a negative size.
Instead, let's use uintmax_t, which should be at least 64
bits on modern platforms.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      0974c117
    • M
      t1010-mktree: Adjust expected result to code and documentation · 53b3c47d
      由 Michael J Gruber 提交于 
      The last two tests here were always supposed to fail in the sense
that, according to code and documentation, mktree should read non-recursive
ls-tree output, but not recursive one, and therefore explicitely refuses
to deal with slashes.

Adjust the test (must_fail) so that it succeeds when mktree dies on
slashes.
Signed-off-by: NMichael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      53b3c47d
    • T
      combined diff: correctly handle truncated file · 21798708
      由 Thomas Rast 提交于 
      Consider an evil merge of two commits A and B, both of which have a
file 'foo', but the merge result does not have that file.

The combined-diff code learned in 4462731e (combine-diff: do not punt
on removed or added files., 2006-02-06) to concisely show only the
removal, since that is the evil part and the previous contents are
presumably uninteresting.

However, to diagnose an empty merge result, it overloaded the variable
that holds the file's length.  This means that the check also triggers
for truncated files.  Consequently, such files were not shown in the
diff at all despite the merge being clearly evil.

Fix this by adding a new variable that distinguishes whether the file
was deleted (which is the case 4462731e handled) or truncated.  In the
truncated case, we show the full combined diff again, which is rather
spammy but at least does not hide the evilness.
Reported-by: NDavid Martínez Martí <desarrollo@gestiweb.com>
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      21798708
  35. 15 4月, 2010 1 次提交
    • J
      Document new "already-merged" rule for branch -d · fff0d0ab
      由 Jonathan Nieder 提交于 
      v1.7.0-rc0~18^2 (branch -d: base the "already-merged" safety on the
branch it merges with, 2009-12-29) taught ‘git branch’ a new heuristic
for when it is safe to delete a branch without forcing the issue.  It
is safe to delete a branch "topic" without second thought if:

 - the branch "topic" is set up to pull from a (remote-tracking,
   usually) branch and is fully merged in that "upstream" branch, or

 - there is no branch.topic.merge configuration and branch "topic" is
   fully merged in the current HEAD.

Update the man page to acknowledge the new rules.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      fff0d0ab