summaryrefslogtreecommitdiff
path: root/builtin-apply.c
AgeCommit message (Collapse)AuthorFilesLines
2009-04-15builtin-apply: keep information about files to be deletedLibravatar Michał Kiedrowicz1-7/+46
Example correct diff generated by `diff -M -B' might look like this: diff --git a/file1 b/file2 similarity index 100% rename from file1 rename to file2 diff --git a/file2 b/file1 similarity index 100% rename from file2 rename to file1 Information about removing `file2' comes after information about creation of new `file2' (renamed from `file1'). Existing implementation isn't able to apply such patch, because it has to know in advance which files will be removed. This patch populates fn_table with information about removal of files before calling check_patch() for each patch to be applied. Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-23builtin-apply: use warning() instead of fprintf(stderr, "warning: ")Libravatar Miklos Vajna1-8/+7
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-18apply: hide unused options from short helpLibravatar Michele Ballabio1-4/+4
The options "--binary" and "--allow-binary-replacement" of git-apply are no-op and maintained for backward compatibility, so avoid to show them in the short help screen. Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-18apply: consistent spelling of "don't"Libravatar Michele Ballabio1-1/+1
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-09lstat_cache(): swap func(length, string) into func(string, length)Libravatar Kjetil Barvik1-1/+1
Swap function argument pair (length, string) into (string, length) to conform with the commonly used order inside the GIT source code. Also, add a note about this fact into the coding guidelines. Signed-off-by: Kjetil Barvik <barvik@broadpark.no> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-04Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* 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
2009-02-03Merge branch 'maint-1.6.0' into maintLibravatar Junio C Hamano1-1/+1
* 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
2009-02-03apply: fix access to an uninitialized mode variable, found by valgrindLibravatar Johannes Schindelin1-1/+1
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>
2009-01-31Merge branch 'jc/maint-apply-fix'Libravatar Junio C Hamano1-1/+1
* jc/maint-apply-fix: builtin-apply.c: do not set bogus mode in check_preimage() for deleted path
2009-01-28builtin-apply.c: do not set bogus mode in check_preimage() for deleted pathLibravatar Junio C Hamano1-1/+1
If it is deleted, it is deleted. Do not set the current mode to it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-21Merge branch 'lt/maint-wrap-zlib'Libravatar Junio C Hamano1-2/+3
* lt/maint-wrap-zlib: Wrap inflate and other zlib routines for better error reporting Conflicts: http-push.c http-walker.c sha1_file.c
2009-01-17Merge branch 'mv/apply-parse-opt'Libravatar Junio C Hamano1-126/+140
* mv/apply-parse-opt: Resurrect "git apply --flags -" to read from the standard input parse-opt: migrate builtin-apply.
2009-01-13Merge branch 'ap/maint-apply-modefix' into maintLibravatar Junio C Hamano1-1/+3
* ap/maint-apply-modefix: builtin-apply: prevent non-explicit permission changes
2009-01-11Wrap inflate and other zlib routines for better error reportingLibravatar Linus Torvalds1-2/+3
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>
2009-01-09Resurrect "git apply --flags -" to read from the standard inputLibravatar Junio C Hamano1-14/+5
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>
2009-01-03Merge branch 'ap/maint-apply-modefix'Libravatar Junio C Hamano1-1/+3
* ap/maint-apply-modefix: builtin-apply: prevent non-explicit permission changes
2009-01-02builtin-apply: prevent non-explicit permission changesLibravatar Junio C Hamano1-1/+3
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>
2008-12-30parse-opt: migrate builtin-apply.Libravatar Miklos Vajna1-129/+152
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>
2008-12-17Add generic 'strbuf_readlink()' helper functionLibravatar Linus Torvalds1-4/+2
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>
2008-10-26Merge branch 'ar/maint-mksnpath' into HEADLibravatar Junio C Hamano1-2/+2
* 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
2008-10-26Fix potentially dangerous uses of mkpath and git_pathLibravatar Alex Riesen1-2/+2
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>
2008-10-12Merge branch 'maint'Libravatar Shawn O. Pearce1-0/+7
* maint: test-lib: fix broken printf git apply --directory broken for new files
2008-10-12Replace calls to strbuf_init(&foo, 0) with STRBUF_INIT initializerLibravatar Brandon Casey1-18/+8
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>
2008-10-12git apply --directory broken for new filesLibravatar Jeff King1-0/+7
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>
2008-10-09Merge branch 'maint'Libravatar Shawn O. Pearce1-1/+1
* 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
2008-10-09builtin-apply: fix typo leading to stack corruptionLibravatar Imre Deak1-1/+1
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>
2008-10-06do not segfault if make_cache_entry failedLibravatar Dmitry Potapov1-0/+2
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-06do not segfault if make_cache_entry failedLibravatar Dmitry Potapov1-0/+2
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-09-29Merge branch 'bc/master-diff-hunk-header-fix'Libravatar Shawn O. Pearce1-9/+2
* 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
2008-09-29Use remove_path from dir.c instead of own implementationLibravatar Alex Riesen1-9/+2
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>
2008-09-06git-apply:--include=pathspecLibravatar Junio C Hamano1-15/+33
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>
2008-09-03Merge branch 'ho/dashless' into maintLibravatar Junio C Hamano1-4/+4
* 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
2008-08-31'git foo' program identifies itself without dash in die() messagesLibravatar Junio C Hamano1-3/+3
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>
2008-08-30Start conforming code to "git subcmd" styleLibravatar Heikki Orsila1-1/+1
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>
2008-08-30git-apply: Loosen "match_beginning" logicLibravatar Junio C Hamano1-1/+4
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>
2008-07-21Rename path_list to string_listLibravatar Johannes Schindelin1-8/+8
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>
2008-07-13Make usage strings dash-lessLibravatar Stephan Beyer1-1/+1
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>
2008-07-09apply: fix copy/rename breakageLibravatar Junio C Hamano1-3/+7
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>
2008-07-09Merge branch 'js/apply-root'Libravatar Junio C Hamano1-0/+24
* 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>"
2008-07-06git-apply --directory: make --root more similar to GNU diffLibravatar Junio C Hamano1-2/+2
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>
2008-07-05Fix apply --recount handling of no-EOL lineLibravatar Thomas Rast1-1/+1
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>
2008-07-02apply --root: thinkofix.Libravatar Junio C Hamano1-2/+2
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>
2008-07-01Teach "git apply" to prepend a prefix with "--root=<root>"Libravatar Johannes Schindelin1-0/+24
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>
2008-07-01Merge branch 'js/apply-recount'Libravatar Junio C Hamano1-7/+68
* js/apply-recount: Allow git-apply to recount the lines in a hunk (AKA recountdiff)
2008-07-01Merge branch 'jc/checkdiff'Libravatar Junio C Hamano1-3/+2
* 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
2008-06-28Allow git-apply to recount the lines in a hunk (AKA recountdiff)Libravatar Johannes Schindelin1-7/+68
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>
2008-06-27git-apply: handle a patch that touches the same path more than once betterLibravatar Don Zickus1-10/+72
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>
2008-06-26check_and_emit_line(): rename and refactorLibravatar Junio C Hamano1-3/+2
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>
2008-05-25Merge branch 'js/config-cb'Libravatar Junio C Hamano1-3/+3
* js/config-cb: Provide git_config with a callback-data parameter Conflicts: builtin-add.c builtin-cat-file.c
2008-05-17builtin-apply: do not declare patch is creation when we do not know itLibravatar Junio C Hamano1-15/+0
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>