Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 19 10月, 2009 2 次提交
  3. 17 10月, 2009 3 次提交
  5. 15 10月, 2009 1 次提交
    • S
      sha1_file: Fix infinite loop when pack is corrupted · b3118bdc
      由 Shawn O. Pearce 提交于 
      Some types of corruption to a pack may confuse the deflate stream
which stores an object.  In Andy's reported case a 36 byte region
of the pack was overwritten, leading to what appeared to be a valid
deflate stream that was trying to produce a result larger than our
allocated output buffer could accept.

Z_BUF_ERROR is returned from inflate() if either the input buffer
needs more input bytes, or the output buffer has run out of space.
Previously we only considered the former case, as it meant we needed
to move the stream's input buffer to the next window in the pack.

We now abort the loop if inflate() returns Z_BUF_ERROR without
consuming the entire input buffer it was given, or has filled
the entire output buffer but has not yet returned Z_STREAM_END.
Either state is a clear indicator that this loop is not working
as expected, and should not continue.

This problem cannot occur with loose objects as we open the entire
loose object as a single buffer and treat Z_BUF_ERROR as an error.
Reported-by: NAndy Isaacson <adi@hexapodia.org>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Acked-by: NNicolas Pitre <nico@fluxnic.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      b3118bdc
  7. 14 10月, 2009 3 次提交
  9. 13 10月, 2009 2 次提交
  11. 10 10月, 2009 20 次提交
  13. 09 10月, 2009 9 次提交
    • J
      Merge git://git.bogomips.org/git-svn · 63d129d9
      由 Junio C Hamano 提交于 
      * git://git.bogomips.org/git-svn:
  git-svn: Avoid spurious errors when rewriteRoot is used.
      63d129d9
    • A
      git-svn: Avoid spurious errors when rewriteRoot is used. · c03c1f79
      由 Alexander Gavrilov 提交于 
      After doing a rebase, git-svn checks that the SVN URL
is what it expects. However, it does not account for
rewriteRoot, which is a legitimate way for the URL
to change. This produces a lot of spurious errors.

[ew: fixed line wrapping]
Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com>
Acked-by: NEric Wong <normalperson@yhbt.net>
      c03c1f79
    • J
      Merge branch 'ms/msvc' · 8ba5effa
      由 Junio C Hamano 提交于 
      * ms/msvc:
  Fix the exit code of MSVC build scripts on cygwin
  Fix MSVC build on cygwin
      8ba5effa
    • J
      Update draft release notes to 1.6.5 · dc3c7a72
      由 Junio C Hamano 提交于
      dc3c7a72
    • J
      Merge branch 'maint' · bf8fc21c
      由 Junio C Hamano 提交于 
      * maint:
  ls-files: die instead of fprintf/exit in -i error
      bf8fc21c
    • B
      Makefile: add a note about the NO_MMAP setting on IRIX and IRIX64 · 651aef34
      由 Brandon Casey 提交于 
      When git is compiled with the MIPSpro 7.4.4m compiler, and NO_PTHREADS is
set, and NO_MMAP is _not_ set, then git segfaults when trying to access the
first entry in a reflog.  If NO_PTHREADS is not set (which implies that the
pthread library is linked in), or NO_MMAP _is_ set, then the segfault is
not encountered.  The conservative choice has been made to set NO_MMAP in
the Makefile to avoid this flaw.  The GNU C compiler does not produce this
behavior.

The segfault happens in refs.c:read_ref_at().  The mmap succeeds, and the
loop is executed properly until rec is rewound into the first line (reflog
entry) of the file.  The segfault is caught by test 28 of
t1400-update-ref.sh which fails when 'git rev-parse --verify "master@{May 25
2005}"' is called.

So, add a comment in the Makefile to describe why NO_MMAP is set and as a
hint to those who may be interested in unsetting it.
Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      651aef34
    • B
      ls-files: die instead of fprintf/exit in -i error · ac78b009
      由 Ben Walton 提交于 
      When ls-files was called with -i but no exclude pattern, it was
calling fprintf(stderr, "...", NULL) and then exiting.  On Solaris,
passing NULL into fprintf was causing a segfault.  On glibc systems,
it was simply producing incorrect output (eg: "(null)": ...).  The
NULL pointer was a result of argv[0] not being preserved by the option
parser.  Instead of requesting that the option parser preserve
argv[0], use die() with a constant string.

A trigger for this bug was: `git ls-files -i`
Signed-off-by: NBen Walton <bwalton@artsci.utoronto.ca>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ac78b009
    • B
      Makefile: enable THREADED_DELTA_SEARCH on IRIX and IRIX64 · 817350d3
      由 Brandon Casey 提交于 
      Since commit dcda3614 removed the use of a variable length array from
builtin-pack-objects.c, it is now safe to compile with the threaded delta
search feature enabled.  Formerly, the MIPSpro 7.4.4m compiler warned that
variable length arrays should not be used with pthreads.
Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      817350d3
    • R
      Fix the exit code of MSVC build scripts on cygwin · b5d18b8e
      由 Ramsay Jones 提交于 
      During an MSVC build on cygwin, the make program did not notice
when the compiler or linker exited with an error. This was caused
by the scripts exiting with the value returned by system() directly.

On POSIX-like systems, such as cygwin, the return value of system()
has the exit code of the executed command encoded in the first byte
(ie the value is shifted up by 8 bits). This allows the bottom
7 bits to contain the signal number of a terminated process, while
the eighth bit indicates whether a core-dump was produced. (A value
of -1 indicates that the command failed to execute.)

The make program, however, expects the exit code to be encoded in the
bottom byte. Futhermore, it apparently masks off and ignores anything
in the upper bytes.

However, these scripts are (naturally) intended to be used on the
windows platform, where we can not assume POSIX-like semantics from
a perl implementation (eg ActiveState). So, in general, we can not
assume that shifting the return value right by eight will get us
the exit code.

In order to improve portability, we assume that a zero return from
system() indicates success, whereas anything else indicates failure.
Since we don't need to know the exact exit code from the compiler
or linker, we simply exit with 0 (success) or 1 (failure).
Signed-off-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      b5d18b8e