Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 01 3月, 2007 3 次提交
  3. 28 2月, 2007 16 次提交
  5. 27 2月, 2007 10 次提交
    • N
      get rid of lookup_object_type() · 0ab17950
      由 Nicolas Pitre 提交于 
      This function is called only once in the whole source tree.  Let's move
its code inline instead, which is also in the spirit of removing as much
object type char arrays as possible (not that this patch does anything for
that but at least it is now a local matter).
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      0ab17950
    • N
      convert object type handling from a string to a number · 21666f1a
      由 Nicolas Pitre 提交于 
      We currently have two parallel notation for dealing with object types
in the code: a string and a numerical value.  One of them is obviously
redundent, and the most used one requires more stack space and a bunch
of strcmp() all over the place.

This is an initial step for the removal of the version using a char array
found in object reading code paths.  The patch is unfortunately large but
there is no sane way to split it in smaller parts without breaking the
system.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      21666f1a
    • N
      formalize typename(), and add its reverse type_from_string() · df843662
      由 Nicolas Pitre 提交于 
      Sometime typename() is used, sometimes type_names[] is accessed directly.
Let's enforce typename() all the time which allows for validating the
type.

Also let's add a function to go from a name to a type and use it instead
of manual memcpy() when appropriate.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      df843662
    • N
      sha1_file.c: don't ignore an error condition in sha1_loose_object_info() · 9ba63031
      由 Nicolas Pitre 提交于 
      Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      9ba63031
    • N
      sha1_file.c: cleanup "offset" usage · 2b87c45b
      由 Nicolas Pitre 提交于 
      First there are too many offsets there and it is getting confusing.
So 'offset' is now 'curpos' to distinguish from other offsets like
'obj_offset'.

Then structures like x = foo(x, &y) are now done as y = foo(&x).
It looks more natural that the result y be returned directly and
x be passed as reference to be updated in place.  This has the effect
of reducing some line length and removing a few, needing a bit less
stack space, and it even reduces the compiled code size.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      2b87c45b
    • N
      sha1_file.c: cleanup hdr usage · d65a16f6
      由 Nicolas Pitre 提交于 
      Let's have hdr be a simple char pointer/array when possible, and let's
reduce its storage to 32 bytes.  Especially for sha1_loose_object_info()
where 128 bytes is way excessive and wastes extra CPU cycles inflating.

The object type is already restricted to 10 bytes in parse_sha1_header()
and the size, even if it is 64 bits, will fit in 20 decimal numbers.  So
32 bytes is plenty.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      d65a16f6
    • J
      Merge branch 'maint' · 4e4b55dd
      由 Junio C Hamano 提交于 
      * maint:
  git-apply: do not fix whitespaces on context lines.
  diff --cc: integer overflow given a 2GB-or-larger file
  mailinfo: do not get confused with logical lines that are too long.
      4e4b55dd
    • J
      git-apply: do not fix whitespaces on context lines. · 63e50d49
      由 Junio C Hamano 提交于 
      Internal function apply_line() is called to copy both context lines
and added lines to the output buffer, while possibly fixing the
whitespace breakages depending on --whitespace=strip settings.
However, it did its fix-up on both context lines and added lines.

This resulted in two symptoms:

 (1) The number of lines reported to have been fixed up included
     these context lines.

 (2) However, the lines actually shown were limited to the added
     lines that had whitespace breakages.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      63e50d49
    • J
      diff --cc: integer overflow given a 2GB-or-larger file · ee24ee55
      由 Jim Meyering 提交于 
      Few of us use git to compare or even version-control 2GB files,
but when we do, we'll want it to work.

Reading a recent patch, I noticed two lines like this:

   int len = st.st_size;

Instead of "int", that should be "size_t".  Otherwise, in the
non-symlink case, with 64-bit size_t, if the file's size is 2GB,
the following xmalloc will fail:

   result = xmalloc(len + 1);

trying to allocate 2^64 - 2^31 + 1 bytes (assuming sign-extension
in the int-to-size_t promotion).  And even if it didn't fail, the
subsequent "result[len] = 0;" would be equivalent to an unpleasant
"result[-2147483648] = 0;"

The other nearby "int"-declared size variable, sz, should also be of
type size_t, for the same reason.  If sz ever wraps around and becomes
negative, xread will corrupt memory _before_ the "result" buffer.
Signed-off-by: NJim Meyering <jim@meyering.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      ee24ee55
    • L
      mailinfo: do not get confused with logical lines that are too long. · 34fc5cef
      由 Linus Torvalds 提交于 
      It basically considers all the continuation lines to be lines of their
own, and if the total line is bigger than what we can fit in it, we just
truncate the result rather than stop in the middle and then get confused
when we try to parse the "next" line (which is just the remainder of the
first line).

[jc: added test, and tightened boundary a bit per list discussion.]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      34fc5cef
  7. 26 2月, 2007 11 次提交