- 25 3月, 2009 1 次提交
-
-
由 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>
-
- 23 3月, 2009 1 次提交
-
-
由 David Aguilar 提交于
The 'Everyday GIT' guide was using the old dashed form of git-init. Signed-off-by: NDavid Aguilar <davvid@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 3月, 2009 4 次提交
-
-
由 Junio C Hamano 提交于
* ks/maint-1.6.0-mailinfo-folded: mailinfo: tests for RFC2047 examples mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)' mailinfo: 'From:' header should be unfold as well mailinfo: correctly handle multiline 'Subject:' header
-
由 Junio C Hamano 提交于
* cc/maint-1.6.0-bisect-fix: bisect: fix another instance of eval'ed string bisect: fix quoting TRIED revs when "bad" commit is also "skip"ped
-
由 Junio C Hamano 提交于
* fg/maint-1.6.0-exclude-bq: Support "\" in non-wildcard exclusion entries
-
由 Junio C Hamano 提交于
* jc/maint-1.6.0-split-diff-metainfo: diff.c: output correct index lines for a split diff
-
- 01 3月, 2009 1 次提交
-
-
由 Danijel Tasov 提交于
Signed-off-by: NDanijel Tasov <dt@korn.shell.la> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 2月, 2009 1 次提交
-
-
由 Christian Couder 提交于
When there is nothing to be skipped, the output from rev-list --bisect-vars was eval'ed without first being strung together with &&; this is probably not a problem as it is much less likely to be a bad input than the list handcrafted by the filter_skip function, but it still is a good discipline. Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 2月, 2009 1 次提交
-
-
由 Christian Couder 提交于
When the "bad" commit was also "skip"ped and when more than one commit was skipped, the "filter_skipped" function would have printed something like: bisect_rev=<hash1>|<hash2> (where <hash1> and <hash2> are hexadecimal sha1 hashes) and this would have been evaled later as piping "bisect_rev=<hash1>" into "<hash2>", which would have failed. So this patch makes the "filter_skipped" function properly quote what it outputs, so that it will print something like: bisect_rev='<hash1>|<hash2>' which will be properly evaled later. The caller was not stopping properly because the scriptlet this function returned to be evaled was not strung together with && and because of this, an error in an earlier part of the output was simply ignored. A test case is added to the test suite. And while at it, we also initialize the VARS, FOUND and TRIED variables, so that we protect ourselves from environment variables the user may have with these names. Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 2月, 2009 1 次提交
-
-
由 Finn Arne Gangstad 提交于
"\" was treated differently in exclude rules depending on whether a wildcard match was done. For wildcard rules, "\" was de-escaped in fnmatch, but this was not done for other rules since they used strcmp instead. A file named "#foo" would not be excluded by "\#foo", but would be excluded by "\#foo*". We now treat all rules with "\" as wildcard rules. Another solution could be to de-escape all non-wildcard rules as we read them, but we would have to do the de-escaping exactly as fnmatch does it to avoid inconsistencies. Signed-off-by: NFinn Arne Gangstad <finnag@pvv.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 2月, 2009 3 次提交
-
-
由 Junio C Hamano 提交于
Some platforms refuse to rename a file that is open. When repacking an already packed repository without adding any new object, the resulting pack will contain the same set of objects as an existing pack, and on such platforms, a newly created packfile cannot replace the existing one. The logic detected this issue but did not try hard enough to recover from it. Especially because the files that needs renaming come in pairs, there potentially are different failure modes that one can be renamed but the others cannot. Asking manual recovery to end users were error prone. This patch tries to make it more robust by first making sure all the existing files that need to be renamed have been renamed before continuing, and attempts to roll back if some failed to rename. This is based on an initial patch by Robin Rosenberg. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Elijah Newren 提交于
fast-export will only list as parents those commits which have already been traversed (making it appear as if merges have been squashed if not all parents have been traversed). To avoid this silent squashing of merge commits, we request commits in topological order. Signed-off-by: NElijah Newren <newren@gmail.com> Acked-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Shawn O. Pearce 提交于
There is some risk that re-opening a regenerated pack file with different offsets could leave stale entries within the delta base cache that could be matched up against other objects using the same "struct packed_git*" and pack offset. Throwing away the entire delta base cache in this case is safer, as we don't have to worry about a recycled "struct packed_git*" matching to the wrong base object, resulting in delta apply errors while unpacking an object. Suggested-by: NDaniel Barkalow <barkalow@iabervon.org> Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 2月, 2009 1 次提交
-
-
由 Shawn O. Pearce 提交于
Otherwise we may reuse the same memory address for a totally different "struct packed_git", and a previously cached object from the prior occupant might be returned when trying to unpack an object from the new pack. Found-by: NDaniel Barkalow <barkalow@iabervon.org> Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 05 2月, 2009 4 次提交
-
-
由 David J. Mellor 提交于
After the git-core package was renamed to git, git help -w was still looking for files in /usr/share/doc/git-core-$VERSION instead of /usr/share/doc/git-$VERSION. Signed-off-by: NDavid J. Mellor <dmellor@whistlingcat.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Matthieu Moy 提交于
The previous code was failing in the case where one moves an unversionned file to an existing destination, with mv -f: the "existing destination" was checked first, and the error was cancelled by the force flag. We now check the unrecoverable error first, which fixes the bug. Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Matthieu Moy 提交于
This currently fails with: git: builtin-mv.c:217: cmd_mv: Assertion `pos >= 0' failed. Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Matthieu Moy 提交于
Without this, the exit status is only the one of the last line. Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 2月, 2009 4 次提交
-
-
由 William Pursell 提交于
These days you must explicitly say "git stash save <comment>". Signed-off-by: NWilliam Pursell <bill.pursell@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Guanqun Lu 提交于
5c5ba73b (Makefile: Use generic rule to build test programs, 2007-05-31) tried to use generic rule to build test programs, but it misses the file 'dump-cache-tree.c', since its name is not prefixed by 'test-'. This commit solves this little problem by renaming this file instead of carrying out an explicit rule in Makefile. Signed-off-by: NGuanqun Lu <guanqun.lu@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Guanqun Lu 提交于
Signed-off-by: NGuanqun Lu <guanqun.lu@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
When 'tpatch' was initialized successfully, st_mode was already taken from the previous diff. We should not try to override it with data from an lstat() that was never called. This is a companion patch to 7a07841c(git-apply: handle a patch that touches the same path more than once better). Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 03 2月, 2009 1 次提交
-
-
由 Junio C Hamano 提交于
We forgot to pass this option to the external grep process. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 2月, 2009 1 次提交
-
-
由 René Scharfe 提交于
The parameter n of unpack_callback() can have a value of up to MAX_UNPACK_TREES. The check at the top of unpack_trees() (its only (indirect) caller) makes sure it cannot exceed this limit. unpack_callback() passes it and the array src to unpack_nondirectories(), which has this loop: for (i = 0; i < n; i++) { /* ... */ src[i + o->merge] = o->df_conflict_entry; o->merge can be 0 or 1, so unpack_nondirectories() potentially accesses the array src at index MAX_UNPACK_TREES. This patch makes it big enough. Reported-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NRené Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 1月, 2009 3 次提交
-
-
由 Jeff King 提交于
The size of the content we are adding may be larger than 2.1G (i.e., "git add gigantic-file"). Most of the code-path to do so uses size_t or unsigned long to record the size, but write_loose_object uses a signed int. On platforms where "int" is 32-bits (which includes x86_64 Linux platforms), we end up passing malloc a negative size. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Kirill Smelkov 提交于
Also as suggested by Junio, in order to try to catch other MIME problems, test cases from the "8. Examples" section of RFC2047 are added to t5100 testsuite as well. Signed-off-by: NKirill Smelkov <kirr@landau.phys.spbu.ru>
-
由 Kirill Smelkov 提交于
Signed-off-by: NKirill Smelkov <kirr@mns.spb.ru>
-
- 28 1月, 2009 2 次提交
-
-
由 Johannes Schindelin 提交于
When normalizing an absolute path, we might have to add a slash _and_ a NUL to the buffer, so the buffer was one too small. Let's just future proof the code and alloc PATH_MAX + 1 bytes. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
When get_sha1_basic() is passed a buffer of len 0, it should not check if buf[len-1] is a curly bracket. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 1月, 2009 1 次提交
-
-
由 Junio C Hamano 提交于
A patch that changes the filetype (e.g. regular file to symlink) of a path must be split into a deletion event followed by a creation event, which means that we need to have two independent metainfo lines for each. However, the code reused the single set of metainfo lines. As the blob object names recorded on the index lines are usually not used nor validated on the receiving end, this is not an issue with normal use of the resulting patch. However, when accepting a binary patch to delete a blob, git-apply verified that the postimage blob object name on the index line is 0{40}, hence a patch that deletes a regular file blob that records binary contents to create a blob with different filetype (e.g. a symbolic link) failed to apply. "git am -3" also uses the blob object names recorded on the index line, so it would also misbehave when synthesizing a preimage tree. This moves the code to generate metainfo lines around, so that two independent sets of metainfo lines are used for the split halves. Additional tests by Jeff King. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 1月, 2009 1 次提交
-
-
由 Boyd Stephen Smith Jr 提交于
The documentation for git-describe says the default abbreviation is 8 hexadecimal digits while cache.c clearly shows DEFAULT_ABBREV set to 7. This patch corrects the documentation. Signed-off-by: NBoyd Stephen Smith Jr <bss@iguanasuicide.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 1月, 2009 4 次提交
-
-
由 Christian Couder 提交于
According to the man page, if "git fsck" is passed one or more heads, it should verify connectivity and validity of only objects reachable from the heads it is passed. However, since 5ac0a206 (Make builtin-fsck.c use parse_options., 2007-10-15) the command behaved as if no heads were passed, when given only one argument. Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Markus Heidelberg 提交于
Command line options can share the same paragraph of description, if they are related or synonymous. In these cases they should be written among each other, so that asciidoc can format them itself. Signed-off-by: NMarkus Heidelberg <markus.heidelberg@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Stephan Beyer 提交于
Signed-off-by: NStephan Beyer <s-beyer@gmx.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Stephan Beyer 提交于
git-commit tries to remove the file ./COMMIT_EDITMSG instead of $GIT_DIR/COMMIT_EDITMSG after commit preparation (e.g. running hooks, launching editor). This behavior exists since f5bbc322 "Port git commit to C". Some test cases (e.g. t/t7502-commit.sh) rely on the existence of $GIT_DIR/COMMIT_EDITMSG after committing and, I guess, many people are used to it. So it is best not to remove it. This patch just removes the removal of COMMIT_EDITMSG. Signed-off-by: NStephan Beyer <s-beyer@gmx.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 1月, 2009 3 次提交
-
-
由 Stephan Beyer 提交于
Add a test case for the bugfix introduced by commit c14c3c82 "git-rebase--interactive: auto amend only edited commit". Signed-off-by: NStephan Beyer <s-beyer@gmx.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Stephan Beyer 提交于
Add a test case for the bugfix introduced by commit 8beb1f33 "git-rebase-interactive: do not squash commits on abort". Signed-off-by: NStephan Beyer <s-beyer@gmx.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Stephan Beyer 提交于
The basic idea of t3501 is to check whether revert and cherry-pick works on renamed files. But as there is no pure cherry-pick/revert test, it is good to also check if commits are actually done in that scenario. Signed-off-by: NStephan Beyer <s-beyer@gmx.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 1月, 2009 2 次提交
-
-
由 Michael J Gruber 提交于
The "-k" option to "git mv" should allow specifying multiple untracked files. Currently, multiple untracked files raise an assertion if they appear consecutively as arguments. Fix this by decrementing the loop index after removing one entry from the array of arguments. Signed-off-by: NMichael J Gruber <git@drmicha.warpmail.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael J Gruber 提交于
Add test cases for ignoring nonexisting and untracked files using the -k option to "git mv". There is one known breakage related to multiple untracked files specfied as consecutive arguments. Signed-off-by: NMichael J Gruber <git@drmicha.warpmail.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-