Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 05 9月, 2009 2 次提交
    • J
      apply.c: split check_whitespace() into two · 92a1747e
      由 Junio C Hamano 提交于 
      This splits the logic to record the presence of whitespace errors out of
the check_whitespace() function, which checks and then records.  The new
function, record_ws_error(), can be used by the blank-at-eof check that
does not use ws_check() logic to report its findings in the same output
format.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      92a1747e
    • J
      apply --whitespace=fix: detect new blank lines at eof correctly · efa57443
      由 Junio C Hamano 提交于 
      The command tries to strip blank lines at the end of the file added by a
patch.  It is done by first detecting if a hunk in patch has additional
blank lines at the end of itself, and if so checking if such a hunk
applies at the end of file.  This patch addresses a bug in the logic to
implement the former (the previous one addressed a bug in the latter).

If the original ends with blank lines, often the patch hunk ends like
this:

    @@ -l,5 +m,7 @@$
    _context$
    _context$
    -deleted$
    +$
    +$
    +$
    _$
    _$

where _ stands for SP and $ shows a end-of-line.  This example patch adds
three trailing blank lines, but the code fails to notice it, because it
only pays attention to added blank lines at the very end of the hunk.  In
this example, the three added blank lines do not appear textually at the
end in the patch, even though you can see that they are indeed added at
the end, if you rearrange the diff like this:

    @@ -l,5 +m,7 @@$
    _context$
    _context$
    -deleted$
    _$
    _$
    +$
    +$
    +$

The fix is not to reset the number of (candidate) added blank lines at the
end when the loop sees a context line that is empty.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      efa57443
  3. 04 9月, 2009 1 次提交
    • J
      apply --whitespace=fix: fix handling of blank lines at the eof · ef2035c5
      由 Junio C Hamano 提交于 
      b94f2eda (builtin-apply.c: make it more line oriented, 2008-01-26) broke
the logic used to detect if a hunk adds blank lines at the end of the
file.  With the new code after that commit:

 - img holds the contents of the file that the hunk is being applied to;

 - preimage has the lines the hunk expects to be in img; and

 - postimage has the lines the hunk wants to update the part in img that
   corresponds to preimage with.

and we need to compare if the last line of preimage (not postimage)
matches the last line of img to see if the hunk applies at the end of the
file.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ef2035c5
  5. 28 8月, 2009 2 次提交
  7. 08 8月, 2009 2 次提交
  9. 21 6月, 2009 2 次提交
  11. 15 6月, 2009 1 次提交
  13. 14 6月, 2009 1 次提交
  15. 25 5月, 2009 1 次提交
  17. 11 5月, 2009 2 次提交
  19. 06 5月, 2009 1 次提交
  21. 30 4月, 2009 1 次提交
    • J
      diff -c -p: do not die on submodules · 7dae8b21
      由 Junio C Hamano 提交于 
      The combine diff logic knew only about blobs (and their checked-out form
in the work tree, either regular files or symlinks), and barfed when fed
submodules.  This "externalizes" gitlinks in the same way as the normal
patch generation codepath does (i.e. "Subproject commit Xxx\n") to fix the
issue.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      7dae8b21
  23. 28 4月, 2009 3 次提交
  25. 23 4月, 2009 1 次提交
  27. 19 4月, 2009 2 次提交
  29. 18 4月, 2009 1 次提交
    • T
      Fix buffer overflow in config parser · e0b3cc0d
      由 Thomas Jarosch 提交于 
      When interpreting a config value, the config parser reads in 1+ space
character(s) and puts -one- space character in the buffer as soon as
the first non-space character is encountered (if not inside quotes).

Unfortunately the buffer size check lacks the extra space character
which gets inserted at the next non-space character, resulting in
a crash with a specially crafted config entry.

The unit test now uses Java to compile a platform independent
.NET framework to output the test string in C# :o)

    Read: Thanks to Johannes Sixt for the correct printf call
    which replaces the perl invocation.
Signed-off-by: NThomas Jarosch <thomas.jarosch@intra2net.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      e0b3cc0d
  31. 13 4月, 2009 2 次提交
  33. 09 4月, 2009 1 次提交
    • B
      process_{tree,blob}: Remove useless xstrdup calls · de551d47
      由 Björn Steinbrink 提交于 
      The name of the processed object was duplicated for passing it to
add_object(), but that already calls path_name, which allocates a new
string anyway. So the memory allocated by the xstrdup calls just went
nowhere, leaking memory.

This reduces the RSS usage for a "rev-list --all --objects" by about 10% on
the gentoo repo (fully packed) as well as linux-2.6.git:

    gentoo:
                    | old           | new
    ----------------|-------------------------------
    RSS             |       1537284 |       1388408
    VSZ             |       1816852 |       1667952
    time elapsed    |       1:49.62 |       1:48.99
    min. page faults|        417178 |        379919

    linux-2.6.git:
                    | old           | new
    ----------------|-------------------------------
    RSS             |        324452 |        292996
    VSZ             |        491792 |        460376
    time elapsed    |       0:14.53 |       0:14.28
    min. page faults|         89360 |         81613
Signed-off-by: NBjörn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      de551d47
  35. 08 4月, 2009 3 次提交
  37. 05 4月, 2009 2 次提交
  39. 02 4月, 2009 1 次提交
  41. 31 3月, 2009 3 次提交
  43. 30 3月, 2009 2 次提交
  45. 25 3月, 2009 2 次提交
    • L
      close_sha1_file(): make it easier to diagnose errors · e8bd78c3
      由 Linus Torvalds 提交于 
      A bug report with "unable to write sha1 file" made us realize that we do
not have enough information to guess why close() is failing.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      e8bd78c3
    • N
      avoid possible overflow in delta size filtering computation · 720fe22d
      由 Nicolas Pitre 提交于 
      On a 32-bit system, the maximum possible size for an object is less than
4GB, while 64-bit systems may cope with larger objects.  Due to this
limitation, variables holding object sizes are using an unsigned long
type (32 bits on 32-bit systems, or 64 bits on 64-bit systems).

When large objects are encountered, and/or people play with large delta
depth values, it is possible for the maximum allowed delta size
computation to overflow, especially on a 32-bit system.  When this
occurs, surviving result bits may represent a value much smaller than
what it is supposed to be, or even zero.  This prevents some objects
from being deltified although they do get deltified when a smaller depth
limit is used.  Fix this by always performing a 64-bit multiplication.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      720fe22d
  47. 23 3月, 2009 1 次提交