- 22 10月, 2009 1 次提交
-
-
由 Junio C Hamano 提交于
The loop in get_size_from_delta() feeds a deflated delta data from the pack stream _until_ we get inflated result of 20 bytes[*] or we reach the end of stream. Side note. This magic number 20 does not have anything to do with the size of the hash we use, but comes from 1a3b55c6 (reduce delta head inflated size, 2006-10-18). The loop reads like this: do { in = use_pack(); stream.next_in = in; st = git_inflate(&stream, Z_FINISH); curpos += stream.next_in - in; } while ((st == Z_OK || st == Z_BUF_ERROR) && stream.total_out < sizeof(delta_head)); This git_inflate() can return: - Z_STREAM_END, if use_pack() fed it enough input and the delta itself was smaller than 20 bytes; - Z_OK, when some progress has been made; - Z_BUF_ERROR, if no progress is possible, because we either ran out of input (due to corrupt pack), or we ran out of output before we saw the end of the stream. The fix b3118bdc (sha1_file: Fix infinite loop when pack is corrupted, 2009-10-14) attempted was against a corruption that appears to be a valid stream that produces a result larger than the output buffer, but we are not even trying to read the stream to the end in this loop. If avail_out becomes zero, total_out will be the same as sizeof(delta_head) so the loop will terminate without the "fix". There is no fix from b3118bdc needed for this loop, in other words. The loop in unpack_compressed_entry() is quite a different story. It feeds a deflated stream (either delta or base) and allows the stream to produce output up to what we expect but no more. do { in = use_pack(); stream.next_in = in; st = git_inflate(&stream, Z_FINISH); curpos += stream.next_in - in; } while (st == Z_OK || st == Z_BUF_ERROR) This _does_ risk falling into an endless interation, as we can exhaust avail_out if the length we expect is smaller than what the stream wants to produce (due to pack corruption). In such a case, avail_out will become zero and inflate() will return Z_BUF_ERROR, while avail_in may (or may not) be zero. But this is not a right fix: do { in = use_pack(); stream.next_in = in; st = git_inflate(&stream, Z_FINISH); + if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out) + break; /* wants more input??? */ curpos += stream.next_in - in; } while (st == Z_OK || st == Z_BUF_ERROR) as Z_BUF_ERROR from inflate() may be telling us that avail_in has also run out before reading the end of stream marker. In such a case, both avail_in and avail_out would be zero, and the loop should iterate to allow the end of stream marker to be seen by inflate from the input stream. The right fix for this loop is likely to be to increment the initial avail_out by one (we allocate one extra byte to terminate it with NUL anyway, so there is no risk to overrun the buffer), and break out if we see that avail_out has become zero, in order to detect that the stream wants to produce more than what we expect. After the loop, we have a check that exactly tests this condition: if ((st != Z_STREAM_END) || stream.total_out != size) { free(buffer); return NULL; } So here is a patch (without my previous botched attempts) to fix this issue. The first hunk reverts the corresponding hunk from b3118bdc, and the second hunk is the same fix proposed earlier. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 10月, 2009 1 次提交
-
-
由 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>
-
- 14 10月, 2009 3 次提交
-
-
由 Nicolas Pitre 提交于
Switch to MiB/s when the connection is fast enough (i.e. on a LAN). Signed-off-by: NNicolas Pitre <nico@fluxnic.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Björn Steinbrink 提交于
When we use -b <branch>, we may checkout something else than what the remote's HEAD references, but we still used remote_head to supply the new ref value to the post-checkout hook, which is wrong. So instead of using remote_head to find the value to be passed to the post-checkout hook, we have to use our_head_points_at, which is always correctly setup, even if -b is not used. This also fixes a segfault when "clone -b <branch>" is used with a remote repo that doesn't have a valid HEAD, as in such a case remote_head is NULL, but we still tried to access it. Reported-by: NDevin Cofer <ranguvar@archlinux.us> Signed-off-by: NBjörn Steinbrink <B.Steinbrink@gmx.de> Acked-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Sixt 提交于
All programs, in particular also the stand-alone programs (non-builtins) must call git_extract_argv0_path(argv[0]) in order to help builds that derive the installation prefix at runtime, such as the MinGW build. Without this call, the program segfaults (or raises an assertion failure). Signed-off-by: NJohannes Sixt <j6t@kdbg.org> Tested-by: NMichael Wookey <michaelwookey@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 10月, 2009 2 次提交
-
-
由 Junio C Hamano 提交于
* maint-1.6.4: git-stash documentation: mention default options for 'list'
-
由 Miklos Vajna 提交于
Signed-off-by: NMiklos Vajna <vmiklos@frugalware.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 10月, 2009 20 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Simon Arlott 提交于
Hide find_parent_branch logging when -qq is specified. This eliminates more unnecessary output when run from cron, e.g.: Found possible branch point: http://undernet-ircu.svn.sourceforge.net/svnroot/undernet-ircu/ircu2/trunk => http://undernet-ircu.svn.sourceforge.net/svnroot/undernet-ircu/ircu2/branches/authz, 1919 Found branch parent: (authz) ea061d76aea985dc0208d36fa5e0b2249b698557 Following parent with do_switch Successfully followed parent Acked-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NSimon Arlott <simon@fire.lp0.eu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
When saying the initial branch is equal to the currently active remote branch, it is probably intended that the branch heads point to the same commit. Maybe it would be more useful to a new user to emphasize that the tree contents and history are the same. More important, probably, is that this new branch is set up so that "git pull" merges changes from the corresponding remote branch. The next paragraph addresses that directly. What the reader needs to know to begin with is that (1) the initial branch is your own; if you do not pull, it won't get updated, and that (2) the initial branch starts out at the same commit as the upstream. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
* rs/maint-archive-prefix: Git archive and trailing "/" in prefix
-
由 Junio C Hamano 提交于
* fc/mutt-alias: send-email: fix mutt regex for grouped aliases
-
由 Junio C Hamano 提交于
* ef/msvc-noreturn: add NORETURN_PTR for function pointers increase portability of NORETURN declarations
-
由 Junio C Hamano 提交于
* jk/reflog-date: improve reflog date/number heuristic
-
由 Junio C Hamano 提交于
* ch/am-header: git-am: force egrep to use correct characters set git-am: fixed patch_format detection according to RFC2822
-
由 Björn Gustavsson 提交于
Signed-off-by: NBjörn Gustavsson <bgustavsson@gmail.com> Acked-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Stephen Boyd 提交于
Aliases with newlines have been a problem since commit 56fc25f2 (Bash completion support for remotes in .git/config., 2006-11-05). The chance of the problem occurring has been slim at best, until commit 518ef8f0 (completion: Replace config --list with --get-regexp, 2009-09-11) removed the case statement introduced by commit 56fc25f2. Before removing the case statement, most aliases with newlines would work unless they were specially crafted as follows [alias] foo = "log -1 --pretty='format:%s\nalias.error=broken'" After removing the case statement, a more benign alias like [alias] whowhat = "log -1 --pretty='format:%an <%ae>\n%s'" wont-complete = ... would cause the completion to break badly. For now, revert the removal of the case statement until someone comes up with a better way to get keys from git-config. Signed-off-by: NStephen Boyd <bebarino@gmail.com> Acked-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Stephen Boyd 提交于
After commit 511a3fc1 (wrap git's main usage string., 2009-09-12), the bash completion for git commands includes COMMAND and [ARGS] when it shouldn't. Fix this by grepping more strictly for a line with git commands. It's doubtful whether git will ever have commands starting with anything besides numbers and letters so this should be fine. At least by being stricter we'll know when we break the completion earlier. Signed-off-by: NStephen Boyd <bebarino@gmail.com> Acked-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ingmar Vanhassel 提交于
This fixes an obvious syntax error that snuck in commit 7e787953: syntax error at /home/ingmar/bin//git-import-tars line 143, near "/^$/ { " syntax error at /home/ingmar/bin//git-import-tars line 145, near "} else" syntax error at /home/ingmar/bin//git-import-tars line 152, near "}" Signed-off-by: NIngmar Vanhassel <ingmar@exherbo.org> Acked-and-Tested-by: NPeter Krefting <peter@softwolves.pp.se> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
Idealists may want USE_NSEC to be the default on Linux some day. Point to a patch to better explain the requirements on filesystem code for that to happen. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
It is not necessarily obvious to a git novice what it means for a filesystem tree to be equal to the HEAD. Spell it out. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
The documentation seems to assume that the starting point for a new branch is the tip of an existing (ordinary) branch, but that is not the most common case. More often, "git branch" is used to begin a branch from a remote-tracking branch, a tag, or an interesting commit (e.g. origin/pu^2). Clarify the language so it can apply to these cases. Thanks to Sean Estabrooks for the wording. Also add a pointer to the user's manual for the bewildered. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
Update the documentation for --merged and --no-merged to explain the meaning of the optional parameter introduced in commit 049716b3 (branch --merged/--no-merged: allow specifying arbitrary commit, 2008-07-08). Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
Sounds better this way, at least to my ears. ("The syntax and supported options of git merge" is a plural noun. "the same" instead of "equal" sounds less technical and seems to convey the meaning better here.) Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
The fmt-merge-message builtin can be invoked as "git fmt-merge-msg" rather than through the hard link in GIT_EXEC_PATH. Although this is unlikely to confuse most script writers, it should not hurt to make the documentation a little clearer anyway. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
There is excellent documentation for these options in Documentation/Makefile, but some users may never find it. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
There are several reasons a git-pull invocation might not have anything marked for merge: 1. We're not on a branch, so there is no branch configuration. 2. We're on a branch, but there is no configuration for this branch. 3. We fetched from the configured remote, but the configured branch to merge didn't get fetched (either it doesn't exist, or wasn't part of the fetch refspec). 4. We fetched from the non-default remote, but didn't specify a branch to merge. We can't use the configured one because it applies to the default remote. 5. We fetched from a specified remote, and a refspec was given, but it ended up not fetching anything (this is actually hard to do; if the refspec points to a remote branch and it doesn't exist, then fetch will fail and we never make it to this code path. But if you provide a wildcard refspec like refs/bogus/*:refs/remotes/origin/* then you can see this failure). We have handled (1) and (2) for some time. Recently, commit a6dbf881 added code to handle case (3). This patch handles cases (4) and (5), which previously just fell under other cases, producing a confusing message. While we're at it, let's rewrap the text for case (3), which looks terribly ugly as it is. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 10月, 2009 11 次提交
-
-
git://git.bogomips.org/git-svn由 Junio C Hamano 提交于
* git://git.bogomips.org/git-svn: git-svn: Avoid spurious errors when rewriteRoot is used.
-
由 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>
-
由 Junio C Hamano 提交于
* ms/msvc: Fix the exit code of MSVC build scripts on cygwin Fix MSVC build on cygwin
-
由 Junio C Hamano 提交于
-
由 Junio C Hamano 提交于
* maint: ls-files: die instead of fprintf/exit in -i error
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 Ramsay Jones 提交于
In the MSVC section of the Makefile, BASIC_CFLAGS is set to a value which contains the string "-DWIN32-D_CONSOLE". This results in a (single) malformed -Define being passed to the compiler. At least on my cygwin installation, the msvc compiler seems to ignore this parameter, without issuing an error or warning, and results in the WIN32 and _CONSOLE macros being undefined. This breaks the build. In order to fix the build, we simply insert a space between the two -Define parameters, "-DWIN32" and "-D_CONSOLE", as originally intended. Signed-off-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 René Scharfe 提交于
With --prefix=string that does not end with a slash, the top-level entries are written out with the specified prefix as expected, but no paths in the directories are added. Fix this by adding the prefix in write_archive_entry() instead of letting get_pathspec() and read_tree_recursive() pair; they are designed to only handle prefixes that are path components. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 10月, 2009 2 次提交
-
-
由 Stephen Boyd 提交于
Signed-off-by: NStephen Boyd <bebarino@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Stephen Boyd 提交于
git am learned --scissors, git commit learned --dry-run and git log learned --decorate=long|short recently. Signed-off-by: NStephen Boyd <bebarino@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-