summaryrefslogtreecommitdiff
path: root/builtin-apply.c
AgeCommit message (Collapse)AuthorFilesLines
2007-02-22Merge branches 'lt/crlf' and 'jc/apply-config'Libravatar Junio C Hamano1-22/+133
* lt/crlf: Teach core.autocrlf to 'git apply' t0020: add test for auto-crlf Make AutoCRLF ternary variable. Lazy man's auto-CRLF * jc/apply-config: t4119: test autocomputing -p<n> for traditional diff input. git-apply: guess correct -p<n> value for non-git patches. git-apply: notice "diff --git" patch again Fix botched "leak fix" t4119: add test for traditional patch and different p_value apply: fix memory leak in prefix_one() git-apply: require -p<n> when working in a subdirectory. git-apply: do not lose cwd when run from a subdirectory. Teach 'git apply' to look at $HOME/.gitconfig even outside of a repository Teach 'git apply' to look at $GIT_DIR/config
2007-02-21git-apply: guess correct -p<n> value for non-git patches.Libravatar Junio C Hamano1-2/+57
This enhances the third point in the previous commit. When applying a non-git patch that begins like this: --- 2.6.orig/mm/slab.c +++ 2.6/mm/slab.c @@ -N,M +L,K @@@ ... and if you are in 'mm' subdirectory, we notice that -p2 is the right option to use to apply the patch in file slab.c in the current directory (i.e. mm/slab.c) The guess function also knows about this pattern, where you would need to use -p0 if applying from the top-level: --- mm/slab.c +++ mm/slab.c @@ -N,M +L,K @@@ ... Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-21git-apply: notice "diff --git" patch againLibravatar Junio C Hamano1-7/+16
Earlier one that tried to be too consistent with GNU patch by not stripping the leading path when we _know_ we are in a subdirectory and the patch is relative to the toplevel was a mistake. This fixes it. - No change to behaviour when it is run from the toplevel of the repository. - When run from a subdirectory to apply a git-generated patch, it uses the right -p<n> value automatically, with or without --index nor --cached option. - When run from a subdirectory to apply a randomly generated patch, it wants the right -p<n> value to be given by the user. The second one is a pure improvement to correct inconsistency between --index and non --index case, compared with 1.5.0. The third point could be further improved to guess what the right value for -p<n> should be by looking at the patch, but should be a topic of a separate patch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-21Fix botched "leak fix"Libravatar Junio C Hamano1-2/+8
When (new_name == old_name), the previous one prefixed old_name alone, leaving new_name untouched, and worse yet, left it dangling pointing at an already freed memory location. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20Mechanical conversion to use prefixcmp()Libravatar Junio C Hamano1-6/+6
This mechanically converts strncmp() to use prefixcmp(), but only when the parameters match specific patterns, so that they can be verified easily. Leftover from this will be fixed in a separate step, including idiotic conversions like if (!strncmp("foo", arg, 3)) => if (!(-prefixcmp(arg, "foo"))) This was done by using this script in px.perl #!/usr/bin/perl -i.bak -p if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) { s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|; } if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) { s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|; } and running: $ git grep -l strncmp -- '*.c' | xargs perl px.perl Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-19apply: fix memory leak in prefix_one()Libravatar Johannes Schindelin1-6/+9
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-19git-apply: require -p<n> when working in a subdirectory.Libravatar Junio C Hamano1-14/+28
git-apply running inside a subdirectory, with or without --index, used to always assume that the patch is formatted in such a way to apply with -p1 from the toplevel, but it is more useful and consistent with the use of "GNU patch -p1" if it defaulted to assume that its input is meant to apply at the level it is invoked in. This changes the behaviour. It used to be that the patch generated this way would apply without any trick: edit Documentation/Makefile git diff >patch.file cd Documentation git apply ../patch.file You need to give an explicit -p2 to git-apply now. On the other hand, if you got a patch from somebody else who did not follow "patch is to apply from the top with -p1" convention, the input patch would start with: diff -u Makefile.old Makefile --- Makefile.old +++ Makefile and in such a case, you can apply it with: git apply -p0 patch.file Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-19git-apply: do not lose cwd when run from a subdirectory.Libravatar Junio C Hamano1-4/+4
When a patch modifies (not deletes) the last file in a directory, because we treat a modification just as deletion followed by creation, and deleting the last file in a directory automatically rmdir(2)'s that directory, we ended up removing the directory, which can potentially be the cwd, and then recreating the same directory to create the patch result. Avoid the rmdir step when remove_file() is called only because we are replacing it with the result by later calling create_file(). Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-18Teach 'git apply' to look at $HOME/.gitconfig even outside of a repositoryLibravatar Junio C Hamano1-5/+3
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-17Teach core.autocrlf to 'git apply'Libravatar Junio C Hamano1-6/+28
This teaches git-apply that the data read from and written to the filesystem might need to get converted to adjust for local line-ending convention. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-17Teach 'git apply' to look at $GIT_DIR/configLibravatar Junio C Hamano1-8/+13
When neither --index nor --cached was used, git-apply did not try calling setup_git_directory(), which means it did not look at configuration files at all. This fixes it to call the setup function but still allow the command to be run in a directory not controlled by git. The bug probably meant that 'git apply', not moving up to the toplevel, did not apply properly formatted diffs from the toplevel when you are inside a subdirectory, even though 'git apply --index' would. As a side effect, this patch fixes it as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-16Do not take mode bits from index after type change.Libravatar Junio C Hamano1-1/+1
When we do not trust executable bit from lstat(2), we copied existing ce_mode bits without checking if the filesystem object is a regular file (which is the only thing we apply the "trust executable bit" business) nor if the blob in the index is a regular file (otherwise, we should do the same as registering a new regular file, which is to default non-executable). Noticed by Johannes Sixt. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-20apply --cached: fix crash in subdirectoryLibravatar Johannes Schindelin1-1/+1
The static variable "prefix" was shadowed by an unused parameter of the same name. In case of execution in a subdirectory, the static variable was accessed, leading to a crash. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
2007-01-09git-apply: Remove directories that have become empty after deleting a file.Libravatar Alexandre Julliard1-2/+13
Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-09Merge branch 'maint'Libravatar Junio C Hamano1-1/+2
* maint: Fix "Do not ignore a detected patchfile brokenness." Do not ignore a detected patchfile brokenness.
2007-01-09Fix "Do not ignore a detected patchfile brokenness."Libravatar Junio C Hamano1-1/+2
Returning negative value from there does not stop the caller from using the earlier part. Noticed by Linus. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-09Do not ignore a detected patchfile brokenness.Libravatar Junio C Hamano1-1/+1
find_header() function is used to read and parse the patchfile and it detects errors in the patch, but one place ignored the error and went ahead, which was quite bad. Noticed by Jeff Garzik. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-20simplify inclusion of system header files.Libravatar Junio C Hamano1-1/+0
This is a mechanical clean-up of the way *.c files include system header files. (1) sources under compat/, platform sha-1 implementations, and xdelta code are exempt from the following rules; (2) the first #include must be "git-compat-util.h" or one of our own header file that includes it first (e.g. config.h, builtin.h, pkt-line.h); (3) system headers that are included in "git-compat-util.h" need not be included in individual C source files. (4) "git-compat-util.h" does not have to include subsystem specific header files (e.g. expat.h). Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-24Merge branch 'jc/numstat'Libravatar Junio C Hamano1-1/+5
* jc/numstat: apply --numstat: mark binary diffstat with - -, not 0 0
2006-11-18git-apply: slightly clean up bitfield usageLibravatar Rene Scharfe1-2/+5
This patch fixes a sparse warning about inaccurate_eof being a "dubious one-bit signed bitfield", makes three more binary variables members of this (now unsigned) bitfield and adds a short comment to indicate the nature of two ternary variables. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-14apply --numstat: mark binary diffstat with - -, not 0 0Libravatar Junio C Hamano1-1/+5
We do not even know number of lines so showing it as 0 0 is lying. This would also help Porcelains like cvsexportcommit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-04Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: Remove unsupported C99 style struct initializers in git-archive. Remove SIMPLE_PROGRAMS and make git-daemon a normal program. Use ULONG_MAX rather than implicit cast of -1.
2006-11-04Use ULONG_MAX rather than implicit cast of -1.Libravatar Shawn O. Pearce1-1/+1
At least one (older) version of the Solaris C compiler won't allow 'unsigned long x = -1' without explicitly casting -1 to a type of unsigned long. So instead use ULONG_MAX, which is really the correct constant anyway. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-04Merge branch 'maint'Libravatar Junio C Hamano1-2/+6
* maint: apply: handle "traditional" creation/deletion diff correctly.
2006-11-04apply: handle "traditional" creation/deletion diff correctly.Libravatar Junio C Hamano1-2/+6
We deduced a GNU diff output that does not use /dev/null convention as creation (deletion) diff correctly by looking at the lack of context and deleted lines (added lines), but forgot to reset the new (old) name field properly. This was a regression when we added a workaround for --unified=0 insanity. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-19Merge branch 'maint'Libravatar Junio C Hamano1-0/+9
* maint: git-apply: prepare for upcoming GNU diff -u format change.
2006-10-19git-apply: prepare for upcoming GNU diff -u format change.Libravatar Linus Torvalds1-0/+9
The latest GNU diff from CVS emits an empty line to express an empty context line, instead of more traditional "single white space followed by a newline". Do not get broken by it. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-18Merge early part of branch 'jc/diff-apply-patch'Libravatar Junio C Hamano1-2/+2
2006-10-14Add hash_sha1_file()Libravatar Rene Scharfe1-6/+2
Most callers of write_sha1_file_prepare() are only interested in the resulting hash but don't care about the returned file name or the header. This patch adds a simple wrapper named hash_sha1_file() which does just that, and converts potential callers. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-12apply --numstat -z: line termination fix.Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-29git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 1)Libravatar Junio C Hamano1-2/+2
Somebody was wondering on #git channel why a git generated diff does not apply with GNU patch when the filename contains a SP. It is because GNU patch expects to find TAB (and trailing timestamp) on ---/+++ (old_name and new_name) lines after the filenames. The "diff --git" output format was carefully designed to be compatible with GNU patch where it can, but whitespace characters were always a pain. We can make our output a bit more GNU patch friendly by adding an extra TAB (but not trailing timestamp) to old/new name lines when the filename as a SP in it. This updates git-apply to prepare ourselves to accept such a patch, but we still do not generate output that is patch friendly yet. That change needs to wait until everybody has this change. When a filename contains a real tab, "diff --git" format always c-quotes it as discussed on the list with GNU patch maintainer previously: http://marc.theaimsgroup.com/?l=git&m=112927316408690&w=2 so there should be no downside. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-24git-apply: second war on whitespace.Libravatar Junio C Hamano1-25/+97
This makes --whitespace={warn,error,strip} option to also notice the leading whitespace errors in addition to the trailing whitespace errors. Spaces that are followed by a tab in indent are detected as errors, and --whitespace=strip option fixes them. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-17apply --unidiff-zero: loosen sanity checks for --unidiff=0 patchesLibravatar Junio C Hamano1-33/+79
In "git-apply", we have a few sanity checks and heuristics that expects that the patch fed to us is a unified diff with at least one line of context. * When there is no leading context line in a hunk, the hunk must apply at the beginning of the preimage. Similarly, no trailing context means that the hunk is anchored at the end. * We learn a patch deletes the file from a hunk that has no resulting line (i.e. all lines are prefixed with '-') if it has not otherwise been known if the patch deletes the file. Similarly, no old line means the file is being created. And we declare an error condition when the file created by a creation patch already exists, and/or when a deletion patch still leaves content in the file. These sanity checks are good safety measures, but breaks down when people feed a diff generated with --unified=0. This was recently noticed first by Matthew Wilcox and Gerrit Pape. This adds a new flag, --unified-zero, to allow bypassing these checks. If you are in control of the patch generation process, you should not use --unified=0 patch and fix it up with this flag; rather you should try work with a patch with context. But if all you have to work with is a patch without context, this flag may come handy as the last resort. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-07Make apply --binary a no-op.Libravatar Junio C Hamano1-14/+5
Historically we did not allow binary patch applied without an explicit permission from the user, and this flag was the way to do so. This makes the flag a no-op by always allowing binary patch application. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-02Replace uses of strdup with xstrdup.Libravatar Shawn Pearce1-1/+1
Like xmalloc and xrealloc xstrdup dies with a useful message if the native strdup() implementation returns NULL rather than a valid pointer. I just tried to use xstrdup in new code and found it to be missing. However I expected it to be present as xmalloc and xrealloc are already commonly used throughout the code. [jc: removed the part that deals with last_XXX, which I am finding more and more dubious these days.] Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-27free(NULL) is perfectly valid.Libravatar Junio C Hamano1-4/+2
Jonas noticed some places say "if (X) free(X)" which is totally unnecessary. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-27Merge branch 'jc/apply'Libravatar Junio C Hamano1-25/+153
* jc/apply: git-apply --reject: finishing touches. apply --reject: count hunks starting from 1, not 0 git-apply --verbose git-apply --reject: send rejects to .rej files. git-apply --reject apply --reverse: tie it all together. diff.c: make binary patch reversible. builtin-apply --reverse: two bugfixes.
2006-08-27git-apply --reject: finishing touches.Libravatar Junio C Hamano1-1/+1
After a failed "git am" attempt: git apply --reject --verbose .dotest/patch applies hunks that are applicable and leaves *.rej files the rejected hunks, and it reports what it is doing. With --index, files with a rejected hunk do not get their index entries updated at all, so "git diff" will show the hunks that successfully got applied. Without --verbose to remind the user that the patch updated some other paths cleanly, it is very easy to lose track of the status of the working tree, so --reject implies --verbose. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-23use name[len] in switch directly, instead of creating a shadowed variable.Libravatar Pierre Habouzit1-3/+1
builtin-apply.c defines a local variable 'c' which is used only once and then later gets shadowed by another instance of 'c'. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-23avoid to use error that shadows the function name, use err instead.Libravatar Pierre Habouzit1-3/+3
builtin-apply.c and builtin-push.c uses a local variable called 'error' which shadows the error() function. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-22apply --reject: count hunks starting from 1, not 0Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-18git-apply --verboseLibravatar Junio C Hamano1-2/+36
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-18git-apply --reject: send rejects to .rej files.Libravatar Junio C Hamano1-32/+50
... just like everybody else does, instead of sending it to the standard output, which was just silly. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-17git-apply --rejectLibravatar Junio C Hamano1-22/+94
With the new flag "--reject", hunks that do not apply are sent to the standard output, and the usable hunks are applied. The command itself exits with non-zero status when this happens, so that the user or wrapper can take notice and sort the remaining mess out. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-16apply --reverse: tie it all together.Libravatar Junio C Hamano1-1/+1
Add a few tests, usage string, and documentation. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-16builtin-apply --reverse: two bugfixes.Libravatar Junio C Hamano1-3/+7
Parsing of a binary hunk did not consume the terminating blank line. When applying in reverse, it did not use the second, reverse binary hunk. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-15remove unnecessary initializationsLibravatar David Rientjes1-14/+14
[jc: I needed to hand merge the changes to the updated codebase, so the result needs to be checked.] Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-15make inline is_null_sha1 globalLibravatar David Rientjes1-6/+1
Replace sha1 comparisons to null_sha1 with a global inline (which previously an unused static inline in builtin-apply.c) [jc: with a fix from Jonas Fonseca.] Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-15git-apply --binary: clean up and prepare for --reverseLibravatar Junio C Hamano1-65/+141
This cleans up the implementation of "git-apply --binary", and implements reverse application of binary patches (when git-diff is converted to emit reversible binary patches). Earlier, the types of encoding (either deflated literal or deflated delta) were stored in is_binary field in struct patch, which meant that we cannot store more than one fragment that differ in the encoding for a patch. This moves the information to a field in struct fragment that is otherwise unused for binary patches, and makes it possible to hang two (or more, but two is enough) hunks for a binary patch. The original "binary patch" output from git-diff is internally parsed into an "is_binary" patch with one fragment. Upcoming reversible binary patch output will have two fragments, the first one being the forward patch and the second one the reverse patch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-14git-apply --reverse: simplify reverse option.Libravatar Junio C Hamano1-16/+12
Having is_reverse in each patch did not make sense. This will hopefully simplify the work needed to introduce reversible binary diff format. Signed-off-by: Junio C Hamano <junkio@cox.net>