aboutsummaryrefslogtreecommitdiff
path: root/builtin-apply.c
Commit message (Collapse)AuthorAge
* Merge branch 'maint'Junio C Hamano2009-02-04
|\ | | | | | | | | | | | | | | | | | | | | * maint: User-manual: "git stash <comment>" form is long gone add test-dump-cache-tree in Makefile fix typo in Documentation apply: fix access to an uninitialized mode variable, found by valgrind Conflicts: Makefile
| * Merge branch 'maint-1.6.0' into maintJunio C Hamano2009-02-03
| |\ | | | | | | | | | | | | | | | | | | | | | * maint-1.6.0: User-manual: "git stash <comment>" form is long gone add test-dump-cache-tree in Makefile fix typo in Documentation apply: fix access to an uninitialized mode variable, found by valgrind
| | * apply: fix access to an uninitialized mode variable, found by valgrindJohannes Schindelin2009-02-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 7a07841(git-apply: handle a patch that touches the same path more than once better). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jc/maint-apply-fix'Junio C Hamano2009-01-31
|\ \ \ | | | | | | | | | | | | | | | | * jc/maint-apply-fix: builtin-apply.c: do not set bogus mode in check_preimage() for deleted path
| * | | builtin-apply.c: do not set bogus mode in check_preimage() for deleted pathJunio C Hamano2009-01-28
| |/ / | | | | | | | | | | | | | | | If it is deleted, it is deleted. Do not set the current mode to it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | Merge branch 'ap/maint-apply-modefix' into maintJunio C Hamano2009-01-13
| |\ \ | | | | | | | | | | | | | | | | * ap/maint-apply-modefix: builtin-apply: prevent non-explicit permission changes
* | \ \ Merge branch 'lt/maint-wrap-zlib'Junio C Hamano2009-01-21
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * lt/maint-wrap-zlib: Wrap inflate and other zlib routines for better error reporting Conflicts: http-push.c http-walker.c sha1_file.c
| * | | | Wrap inflate and other zlib routines for better error reportingLinus Torvalds2009-01-11
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | R. Tyler Ballance reported a mysterious transient repository corruption; after much digging, it turns out that we were not catching and reporting memory allocation errors from some calls we make to zlib. This one _just_ wraps things; it doesn't do the "retry on low memory error" part, at least not yet. It is an independent issue from the reporting. Some of the errors are expected and passed back to the caller, but we die when zlib reports it failed to allocate memory for now. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'mv/apply-parse-opt'Junio C Hamano2009-01-17
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | * mv/apply-parse-opt: Resurrect "git apply --flags -" to read from the standard input parse-opt: migrate builtin-apply.
| * | | | Resurrect "git apply --flags -" to read from the standard inputJunio C Hamano2009-01-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous "parse-opt"ification broke git-apply reading from the standard input. "git apply A - C <B" is supposed to read patches from files A, B and C in this order. Before "parse-opt"ification, we used be able to: git apply --stat - --apply <A B to read the patch from file A, showing only the diffstat, and then read the patch from file B, showing the diffstat and actually applying it. Even with this fix we cannot do that anymore, but that is so crazy use case I do not think anybody sane relied on such a broken behaviour. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | parse-opt: migrate builtin-apply.Miklos Vajna2008-12-30
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | The only incompatible change is that the user how have to use '--' before a patch file if it is named "--build-fake-ancestor=something". Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'ap/maint-apply-modefix'Junio C Hamano2009-01-03
|\ \ \ \ | |/ / / |/| | / | | |/ | |/| * ap/maint-apply-modefix: builtin-apply: prevent non-explicit permission changes
| * | builtin-apply: prevent non-explicit permission changesJunio C Hamano2009-01-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A git patch that does not change the executable bit records the mode bits on its "index" line. "git apply" used to interpret this mode exactly the same way as it interprets the mode recorded on "new mode" line, as the wish by the patch submitter to set the mode to the one recorded on the line. The reason the mode does not agree between the submitter and the receiver in the first place is because there is _another_ commit that only appears on one side but not the other since their histories diverged, and that commit changes the mode. The patch has "index" line but not "new mode" line because its change is about updating the contents without affecting the mode. The application of such a patch is an explicit wish by the submitter to only cherry-pick the commit that updates the contents without cherry-picking the commit that modifies the mode. Viewed this way, the current behaviour is problematic, even though the command does warn when the mode of the path being patched does not match this mode, and a careful user could detect this inconsistencies between the patch submitter and the patch receiver. This changes the semantics of the mode recorded on the "index" line; instead of interpreting it as the submitter's wish to set the mode to the recorded value, it merely informs what the mode submitter happened to have, and the presense of the "index" line is taken as submitter's wish to keep whatever the mode is on the receiving end. This is based on the patch originally done by Alexander Potashev with a minor fix; the tests are mine. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Add generic 'strbuf_readlink()' helper functionLinus Torvalds2008-12-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It was already what 'git apply' did in read_old_data(), just export it as a real function, and make it be more generic. In particular, this handles the case of the lstat() st_size data not matching the readlink() return value properly (which apparently happens at least on NTFS under Linux). But as a result of this you could also use the new function without even knowing how big the link is going to be, and it will allocate an appropriately sized buffer. So we pass in the st_size of the link as just a hint, rather than a fixed requirement. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'ar/maint-mksnpath' into HEADJunio C Hamano2008-10-26
|\ \ \ | | |/ | |/| | | | | | | | | | | | | * ar/maint-mksnpath: Fix potentially dangerous uses of mkpath and git_path Fix mkpath abuse in dwim_ref and dwim_log of sha1_name.c Add mksnpath which allows you to specify the output buffer
| * | Fix potentially dangerous uses of mkpath and git_pathAlex Riesen2008-10-26
| | | | | | | | | | | | | | | | | | | | | | | | Replace them with mksnpath/git_snpath and a local buffer for the resulting string. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'maint'Shawn O. Pearce2008-10-12
|\ \ \ | |/ / | | | | | | | | | | | | * maint: test-lib: fix broken printf git apply --directory broken for new files
| * | git apply --directory broken for new filesJeff King2008-10-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We carefully verify that the input to git-apply is sane, including cross-checking that the filenames we see in "+++" headers match what was provided on the command line of "diff --git". When --directory is used, however, we ended up comparing the unadorned name to one with the prepended root, causing us to complain about a mismatch. We simply need to prepend the root directory, if any, when pulling the name out of the git header. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | | Replace calls to strbuf_init(&foo, 0) with STRBUF_INIT initializerBrandon Casey2008-10-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many call sites use strbuf_init(&foo, 0) to initialize local strbuf variable "foo" which has not been accessed since its declaration. These can be replaced with a static initialization using the STRBUF_INIT macro which is just as readable, saves a function call, and takes up fewer lines. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | | Merge branch 'maint'Shawn O. Pearce2008-10-09
|\ \ \ | |/ / | | | | | | | | | | | | | | | | | | | | | | | | * maint: builtin-apply: fix typo leading to stack corruption git-stash.sh: fix flawed fix of invalid ref handling (commit da65e7c1) builtin-merge.c: allocate correct amount of memory Makefile: do not set NEEDS_LIBICONV for Solaris 8 rebase -i: remove leftover debugging rebase -i: proper prepare-commit-msg hook argument when squashing
| * | builtin-apply: fix typo leading to stack corruptionImre Deak2008-10-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | This typo led to stack corruption for lines with whitespace fixes and length > 1024. Signed-off-by: Imre Deak <imre.deak@gmail.com> Looks-good-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * | do not segfault if make_cache_entry failedDmitry Potapov2008-10-06
| | | | | | | | | | | | | | | Signed-off-by: Dmitry Potapov <dpotapov@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | | do not segfault if make_cache_entry failedDmitry Potapov2008-10-06
| | | | | | | | | | | | | | | Signed-off-by: Dmitry Potapov <dpotapov@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | | Merge branch 'bc/master-diff-hunk-header-fix'Shawn O. Pearce2008-09-29
|\ \ \ | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * bc/master-diff-hunk-header-fix: Clarify commit error message for unmerged files Use strchrnul() instead of strchr() plus manual workaround Use remove_path from dir.c instead of own implementation Add remove_path: a function to remove as much as possible of a path git-submodule: Fix "Unable to checkout" for the initial 'update' Clarify how the user can satisfy stash's 'dirty state' check. t4018-diff-funcname: test syntax of builtin xfuncname patterns t4018-diff-funcname: test syntax of builtin xfuncname patterns make "git remote" report multiple URLs diff hunk pattern: fix misconverted "\{" tex macro introducers diff: fix "multiple regexp" semantics to find hunk header comment diff: use extended regexp to find hunk headers diff: use extended regexp to find hunk headers diff.*.xfuncname which uses "extended" regex's for hunk header selection diff.c: associate a flag with each pattern and use it for compiling regex diff.c: return pattern entry pointer rather than just the hunk header pattern Conflicts: builtin-merge-recursive.c t/t7201-co.sh xdiff-interface.h
| * | Use remove_path from dir.c instead of own implementationAlex Riesen2008-09-29
| | | | | | | | | | | | | | | | | | | | | | | | Besides, it fixes a memleak (builtin-rm.c) and accidental change of the input const argument (builtin-merge-recursive.c). Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | | git-apply:--include=pathspecJunio C Hamano2008-09-06
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows --include=pathspec, similar to --exclude=pathspec. The rule when one or both of these are used is that the include/exclude patterns are examined in the order they are given on the command line, and the first match determines if a patch to each path is used or not. Hence: $ git apply --include='specific.h' --exclude='*.h' <diff would apply the patch to specific.h header file, but all other patches in the input file to other header files are ignored. A patch to a path that does not match any include/exclude pattern is used by default if there is no include pattern on the command line, and ignored if there is any include pattern. This originally came from Joe Perches, but both the design of the semantics and the implementation have been redone complately. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'ho/dashless' into maintJunio C Hamano2008-09-03
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | * ho/dashless: tests: use "git xyzzy" form (t7200 - t9001) tests: use "git xyzzy" form (t7000 - t7199) tests: use "git xyzzy" form (t3600 - t6999) tests: use "git xyzzy" form (t0000 - t3599) 'git foo' program identifies itself without dash in die() messages Start conforming code to "git subcmd" style
| * | 'git foo' program identifies itself without dash in die() messagesJunio C Hamano2008-08-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a mechanical conversion of all '*.c' files with: s/((?:die|error|warning)\("git)-(\S+:)/$1 $2/; The result was manually inspected and no false positive was found. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | Start conforming code to "git subcmd" styleHeikki Orsila2008-08-30
| | | | | | | | | | | | | | | | | | | | | | | | User notifications are presented as 'git cmd', and code comments are presented as '"cmd"' or 'git's cmd', rather than 'git-cmd'. Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | git-apply: Loosen "match_beginning" logicJunio C Hamano2008-08-30
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Even after a handfle attempts, match_beginning logic still has corner cases: 1bf1a85 (apply: treat EOF as proper context., 2006-05-23) 65aadb9 (apply: force matching at the beginning., 2006-05-24) 4be6096 (apply --unidiff-zero: loosen sanity checks ..., 2006-09-17) ee5a317 (Fix "git apply" to correctly enforce "match ..., 2008-04-06) This is a tricky piece of code. We still incorrectly enforce "match_beginning" for -U0 matches. I noticed this while trying out an example sequence from Clemens Buchacher: $ echo a >victim $ git add victim $ echo b >>victim $ git diff -U0 >patch $ cat patch diff --git i/victim w/victim index 7898192..422c2b7 100644 --- i/victim +++ w/victim @@ -1,0 +2 @@ a +b $ git apply --cached --unidiff-zero <patch $ git show :victim b a The change inserts a new line before the second line, but we insist it to be applied at the beginning. As the result, the code refuses to apply it at the original offset, and we end up adding the line at the beginning. Updates to the test script are by Clemens Buchacher. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Rename path_list to string_listJohannes Schindelin2008-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The name path_list was correct for the first usage of that data structure, but it really is a general-purpose string list. $ perl -i -pe 's/path-list/string-list/g' $(git grep -l path-list) $ perl -i -pe 's/path_list/string_list/g' $(git grep -l path_list) $ git mv path-list.h string-list.h $ git mv path-list.c string-list.c $ perl -i -pe 's/has_path/has_string/g' $(git grep -l has_path) $ perl -i -pe 's/path/string/g' string-list.[ch] $ git mv Documentation/technical/api-path-list.txt \ Documentation/technical/api-string-list.txt $ perl -i -pe 's/strdup_paths/strdup_strings/g' $(git grep -l strdup_paths) ... and then fix all users of string-list to access the member "string" instead of "path". Documentation/technical/api-string-list.txt needed some rewrapping, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Make usage strings dash-lessStephan Beyer2008-07-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When you misuse a git command, you are shown the usage string. But this is currently shown in the dashed form. So if you just copy what you see, it will not work, when the dashed form is no longer supported. This patch makes git commands show the dash-less version. For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh generates a dash-less usage string now. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | apply: fix copy/rename breakageJunio C Hamano2008-07-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7ebd52a (Merge branch 'dz/apply-again', 2008-07-01) taught "git-apply" to grok a (non-git) patch that is a concatenation of separate patches that touch the same file number of times, by recording the postimage of patch application of previous round and using it as the preimage for later rounds. This "incremental" mode of patch application fundamentally contradicts with the way git rename/copy patches are designed. When a git patch talks about a file A getting modified, and a new file B created out of A, like this: diff --git a/A b/A --- a/A +++ b/A ... change text here ... diff --git a/A b/B copy from A copy to B --- a/A +++ b/B ... change text here ... the second change to produce B does not depend on what is done to A with the first change in any way. This is explicitly done so for reviewability of individual patches. With this commit, we do not look at 'fn_table' that records the postimage of previous round when applying a patch to produce a new file out of an existing file. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'js/apply-root'Junio C Hamano2008-07-09
|\ \ | | | | | | | | | | | | | | | | | | * js/apply-root: git-apply --directory: make --root more similar to GNU diff apply --root: thinkofix. Teach "git apply" to prepend a prefix with "--root=<root>"
| * | git-apply --directory: make --root more similar to GNU diffJunio C Hamano2008-07-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | Applying a patch in the directory that is different from what the patch records is done with --directory option in GNU diff. The --root option we introduced previously does the same, and we can call it the same way to give users more familiar feel. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | apply --root: thinkofix.Junio C Hamano2008-07-02
| | | | | | | | | | | | | | | | | | | | | | | | The end of a string is string[length-1], not string[length+1]. I pointed it out during the review, but I forgot about it when applying the patch. This should fix it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | Teach "git apply" to prepend a prefix with "--root=<root>"Johannes Schindelin2008-07-01
| |/ | | | | | | | | | | | | | | | | | | | | With "git apply --root=<root>", all file names in the patch are prepended with <root>. If a "-p" value was given, the paths are stripped _before_ prepending <root>. Wished for by HPA. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Fix apply --recount handling of no-EOL lineThomas Rast2008-07-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a patch modifies the last line of a file that previously had no terminating '\n', it looks like -old text \ No newline at end of file +new text Hence, a '\' line does not signal the end of the hunk. This modifies 'git apply --recount' to take this into account. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'js/apply-recount'Junio C Hamano2008-07-01
|\ \ | | | | | | | | | | | | * js/apply-recount: Allow git-apply to recount the lines in a hunk (AKA recountdiff)
| * | Allow git-apply to recount the lines in a hunk (AKA recountdiff)Johannes Schindelin2008-06-28
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes, the easiest way to fix up a patch is to edit it directly, even adding or deleting lines. Now, many people are not as divine as certain benevolent dictators as to update the hunk headers correctly at the first try. So teach the tool to do it for us. [jc: with tests] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jc/checkdiff'Junio C Hamano2008-07-01
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * jc/checkdiff: Fix t4017-diff-retval for white-space from wc Update sample pre-commit hook to use "diff --check" diff --check: detect leftover conflict markers Teach "diff --check" about new blank lines at end checkdiff: pass diff_options to the callback check_and_emit_line(): rename and refactor diff --check: explain why we do not care whether old side is binary
| * | check_and_emit_line(): rename and refactorJunio C Hamano2008-06-26
| |/ | | | | | | | | | | | | | | | | The function name was too bland and not explicit enough as to what it is checking. Split it into two, and call the one that checks if there is a whitespace breakage "ws_check()", and call the other one that checks and emits the line after color coding "ws_check_emit()". Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-apply: handle a patch that touches the same path more than once betterDon Zickus2008-06-27
|/ | | | | | | | | | | | | | | | | | | | | | | | | | When working with a lot of people who backport patches all day long, every once in a while I get a patch that modifies the same file more than once inside the same patch. git-apply either fails if the second change relies on the first change or silently drops the first change if the second change is independent. The silent part is the scary scenario for us. Also this behaviour is different from the patch-utils. I have modified git-apply to create a table of the filenames of files it modifies such that if a later patch chunk modifies a file in the table it will buffer the previously changed file instead of reading the original file from disk. Logic has been put in to handle creations/deletions/renames/copies. All the relevant tests of git-apply succeed. A new test has been added to cover the cases I addressed. The fix is relatively straight-forward. Signed-off-by: Don Zickus <dzickus@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'js/config-cb'v1.5.6-rc0Junio C Hamano2008-05-25
|\ | | | | | | | | | | | | | | | | | | * js/config-cb: Provide git_config with a callback-data parameter Conflicts: builtin-add.c builtin-cat-file.c
| * Provide git_config with a callback-data parameterJohannes Schindelin2008-05-14
| | | | | | | | | | | | | | | | | | | | | | | | git_config() only had a function parameter, but no callback data parameter. This assumes that all callback functions only modify global variables. With this patch, every callback gets a void * parameter, and it is hoped that this will help the libification effort. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | builtin-apply: do not declare patch is creation when we do not know itJunio C Hamano2008-05-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When we see no context nor deleted line in the patch, we used to declare that the patch creates a new file. But some people create an empty file and then apply a patch to it. Similarly, a patch that delete everything is not a deletion patch either. This commit corrects these two issues. Together with the previous commit, it allows a diff between an empty file and a line-ful file to be treated as both creation patch and "add stuff to an existing empty file", depending on the context. A new test t4126 demonstrates the fix. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | builtin-apply: accept patch to an empty fileJunio C Hamano2008-05-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A patch from a foreign SCM (or plain "diff" output) often have both preimage and postimage filename on ---/+++ lines even for a patch that creates a new file. However, when there is a filename for preimage, we used to insist the file to exist (either in the work tree and/or in the index). When we cannot be sure by parsing the patch that it is not a creation patch, we shouldn't complain when if there is no such a file. This commit fixes the logic. Refactor the code that validates the preimage file into a separate function while we are at it, as it is getting rather big. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | builtin-apply: typofixJunio C Hamano2008-05-17
|/ | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Optimize symlink/directory detectionLinus Torvalds2008-05-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the base for making symlink detection in the middle fo a pathname saner and (much) more efficient. Under various loads, we want to verify that the full path leading up to a filename is a real directory tree, and that when we successfully do an 'lstat()' on a filename, we don't get a false positive due to a symlink in the middle of the path that git should have seen as a symlink, not as a normal path component. The 'has_symlink_leading_path()' function already did this, and cached a single level of symlink information, but didn't cache the _lack_ of a symlink, so the normal behaviour was actually the wrong way around, and we ended up doing an 'lstat()' on each path component to check that it was a real directory. This caches the last detected full directory and symlink entries, and speeds up especially deep directory structures a lot by avoiding to lstat() all the directories leading up to each entry in the index. [ This can - and should - probably be extended upon so that we eventually never do a bare 'lstat()' on any path entries at *all* when checking the index, but always check the full path carefully. Right now we do not generally check the whole path for all our normal quick index revalidation. We should also make sure that we're careful about all the invalidation, ie when we remove a link and replace it by a directory we should invalidate the symlink cache if it matches (and vice versa for the directory cache). But regardless, the basic function needs to be sane to do that. The old 'has_symlink_leading_path()' was not capable enough - or indeed the code readable enough - to really do that sanely. So I'm pushing this as not just an optimization, but as a base for further work. ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'maint'Junio C Hamano2008-04-16
|\ | | | | | | | | | | | | | | | | | | * maint: git-bisect: make "start", "good" and "skip" succeed or fail atomically git-am: cope better with an empty Subject: line Ignore leading empty lines while summarizing merges bisect: squelch "fatal: ref HEAD not a symref" misleading message builtin-apply: Show a more descriptive error on failure when opening a patch Clarify documentation of git-cvsserver, particularly in relation to git-shell