summaryrefslogtreecommitdiff
path: root/builtin/apply.c
AgeCommit message (Collapse)AuthorFilesLines
2012-02-03Use correct grammar in diffstat summary lineLibravatar Nguyễn Thái Ngọc Duy1-1/+2
"git diff --stat" and "git apply --stat" now learn to print the line "%d files changed, %d insertions(+), %d deletions(-)" in singular form whenever applicable. "0 insertions" and "0 deletions" are also omitted unless they are both zero. This matches how versions of "diffstat" that are not prehistoric produced their output, and also makes this line translatable. [jc: with help from Thomas Dickey in archaeology of "diffstat"] [jc: squashed Jonathan's updates to illustrations in tutorials and a test] Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-13Merge branch 'bc/maint-apply-check-no-patch'Libravatar Junio C Hamano1-5/+5
* bc/maint-apply-check-no-patch: builtin/apply.c: report error on failure to recognize input t/t4131-apply-fake-ancestor.sh: fix broken test
2011-12-05Merge branch 'ab/clang-lints'Libravatar Junio C Hamano1-3/+0
* ab/clang-lints: cast variable in call to free() in builtin/diff.c and submodule.c apply: get rid of useless x < 0 comparison on a size_t type
2011-12-05builtin/apply.c: report error on failure to recognize inputLibravatar Brandon Casey1-5/+5
When git apply is passed something that is not a patch, it does not produce an error message or exit with a non-zero status if it was not actually "applying" the patch i.e. --check or --numstat etc were supplied on the command line. Fix this by producing an error when apply fails to find any hunks whatsoever while parsing the patch. This will cause some of the output formats (--numstat, --diffstat, etc) to produce an error when they formerly would have reported zero changes and exited successfully. That seems like the correct behavior though. Failure to recognize the input as a patch should be an error. Plus, add a test. Reported-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-06apply: get rid of useless x < 0 comparison on a size_t typeLibravatar Ævar Arnfjörð Bjarmason1-3/+0
According to the C standard size_t is always unsigned, therefore the comparison "n1 < 0 || n2 < 0" when n1 and n2 are size_t will always be false. This was raised by clang 2.9 which throws this warning when compiling apply.c: builtin/apply.c:253:9: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] if (n1 < 0 || n2 < 0) ~~ ^ ~ builtin/apply.c:253:19: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] if (n1 < 0 || n2 < 0) ~~ ^ ~ This check was originally added in v1.6.5-rc0~53^2 by Giuseppe Bilotta while adding an option to git-apply to ignore whitespace differences. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-21Merge branch 'jc/apply-blank-at-eof-fix' into maintLibravatar Junio C Hamano1-2/+9
* jc/apply-blank-at-eof-fix: apply --whitespace=error: correctly report new blank lines at end
2011-10-21Merge branch 'jm/maint-apply-detects-corrupt-patch-header' into maintLibravatar Junio C Hamano1-0/+3
* jm/maint-apply-detects-corrupt-patch-header: fix "git apply --index ..." not to deref NULL
2011-10-19Merge branch 'jm/maint-apply-detects-corrupt-patch-header'Libravatar Junio C Hamano1-0/+3
* jm/maint-apply-detects-corrupt-patch-header: fix "git apply --index ..." not to deref NULL
2011-10-13Merge branch 'jc/apply-blank-at-eof-fix'Libravatar Junio C Hamano1-2/+9
* jc/apply-blank-at-eof-fix: apply --whitespace=error: correctly report new blank lines at end
2011-10-12fix "git apply --index ..." not to deref NULLLibravatar Jim Meyering1-0/+3
I noticed this when "git am CORRUPTED" unexpectedly failed with an odd diagnostic, and even removed one of the files it was supposed to have patched. Reproduce with any valid old/new patch from which you have removed the "+++ b/FILE" line. You'll see a diagnostic like this fatal: unable to write file '(null)' mode 100644: Bad address and you'll find that FILE has been removed. The above is on glibc-based systems. On other systems, rather than getting "null", you may provoke a segfault as git tries to dereference the NULL file name. Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-28apply: use OPT_NOOP_NOARGLibravatar René Scharfe1-7/+2
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-10zlib: zlib can only process 4GB at a timeLibravatar Junio C Hamano1-1/+1
The size of objects we read from the repository and data we try to put into the repository are represented in "unsigned long", so that on larger architectures we can handle objects that weigh more than 4GB. But the interface defined in zlib.h to communicate with inflate/deflate limits avail_in (how many bytes of input are we calling zlib with) and avail_out (how many bytes of output from zlib are we ready to accept) fields effectively to 4GB by defining their type to be uInt. In many places in our code, we allocate a large buffer (e.g. mmap'ing a large loose object file) and tell zlib its size by assigning the size to avail_in field of the stream, but that will truncate the high octets of the real size. The worst part of this story is that we often pass around z_stream (the state object used by zlib) to keep track of the number of used bytes in input/output buffer by inspecting these two fields, which practically limits our callchain to the same 4GB limit. Wrap z_stream in another structure git_zstream that can express avail_in and avail_out in unsigned long. For now, just die() when the caller gives a size that cannot be given to a single zlib call. In later patches in the series, we would make git_inflate() and git_deflate() internally loop to give callers an illusion that our "improved" version of zlib interface can operate on a buffer larger than 4GB in one go. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-16Merge branch 'jc/maint-add-p-overlapping-hunks' into maintLibravatar Junio C Hamano1-3/+6
* jc/maint-add-p-overlapping-hunks: t3701: add-p-fix makes the last test to pass "add -p": work-around an old laziness that does not coalesce hunks add--interactive.perl: factor out repeated --recount option t3701: Editing a split hunk in an "add -p" session add -p: 'q' should really quit
2011-04-29"add -p": work-around an old laziness that does not coalesce hunksLibravatar Junio C Hamano1-3/+6
Since 0beee4c (git-add--interactive: remove hunk coalescing, 2008-07-02), "git add--interactive" behaves lazily and passes overlapping hunks to the underlying "git apply" without coalescing. This was partially corrected by 7a26e65 (its partial revert, 2009-05-16), but overlapping hunks are still passed when the patch is edited. Teach "git apply" the --allow-overlap option that disables a safety feature that avoids misapplication of patches by not applying patches to overlapping hunks, and pass this option form "add -p" codepath. Do not even advertise the option, as this is merely a workaround, and the correct fix is to make "add -p" correctly coalesce adjacent patch hunks. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-15Merge branch 'jc/maint-apply-report-offset'Libravatar Junio C Hamano1-2/+14
* jc/maint-apply-report-offset: apply -v: show offset count when patch did not apply exactly
2011-03-06apply -v: show offset count when patch did not apply exactlyLibravatar Junio C Hamano1-2/+14
When the line number the patch intended to touch does not match the line in the version being patched, GNU patch reports that it applied the hunk at a different line number, with how big an offset. Teach "git apply" to do the same under --verbose option. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-04apply: do not patch lines that were already patchedLibravatar Junio C Hamano1-1/+6
When looking for a place to apply a hunk, we used to check lines that match the preimage of it, starting from the line that the patch wants to apply the hunk at, looking forward and backward with increasing offsets until we find a match. Colin Guthrie found an interesting case where this misapplied a patch that wanted to touch a preimage that consists of } } return 0; } which is a rather unfortunately common pattern. The target version of the file originally had only one such location, but the hunk immediately before that created another instance of such block of lines, and find_pos() happily reported that the preimage of the hunk matched what it wanted to modify. Oops. By marking the lines application of earlier hunks touched and preventing match_fragment() from considering them as a match with preimage of other hunks, we can reduce such an accident. I also considered to teach apply_one_fragment() to take the offset we have found while applying the previous hunk into account when looking for a match with find_pos(), but dismissed that approach, because it would sometimes work better but sometimes worse, depending on the difference between the version the patch was created against and the version the patch is being applied. This does _not_ prevent misapplication of patches to a file that has many similar looking blocks of lines and a preimage cannot identify which one of them should be applied. For that, we would need to scan beyond the first match in find_pos(), and issue a warning (or error out). That will be a separate topic. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-29Merge branch 'fc/apply-p2-get-header-name'Libravatar Junio C Hamano1-14/+14
* fc/apply-p2-get-header-name: test: git-apply -p2 rename/chmod only Fix git-apply with -p greater than 1
2010-11-29Merge branch 'ak/apply-non-git-epoch'Libravatar Junio C Hamano1-6/+29
* ak/apply-non-git-epoch: apply: handle patches with funny filename and colon in timezone apply: Recognize epoch timestamps with : in the timezone
2010-11-24Merge branch 'rs/opt-help-text'Libravatar Junio C Hamano1-1/+1
* rs/opt-help-text: verify-tag: document --verbose branch: improve --verbose description archive: improve --verbose description Describe various forms of "be quiet" using OPT__QUIET add OPT__FORCE add description parameter to OPT__QUIET add description parameter to OPT__DRY_RUN add description parameter to OPT__VERBOSE
2010-11-15add description parameter to OPT__VERBOSELibravatar René Scharfe1-1/+1
Allows better help text to be defined than "be verbose". Also make use of the macro in places that already had a different description. No object code changes intended. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-10apply: handle patches with funny filename and colon in timezoneLibravatar Jonathan Nieder1-2/+22
Some patches have a timezone formatted like '-08:00' instead of '-0800' in their ---/+++ lines (e.g. http://lwn.net/Articles/131729/). Take this into account when searching for the start of the timezone (which is the end of the filename). This does not actually affect the outcome of patching unless (1) a file being patched has a non-' ' whitespace character (e.g., tab) in its filename, or (2) the patch is whitespace-damaged, so the tab between filename and timestamp has been replaced with spaces. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-05Fix git-apply with -p greater than 1Libravatar Federico Cuello1-14/+14
Fix the case when the patch is a rename or mode-change only and -p is used with a value greater than one. The git_header_name function did not remove more than one path component. Signed-off-by: Federico Cuello <fedux@lugmen.org.ar> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-29apply: don't segfault on binary files with missing dataLibravatar Jeff King1-0/+6
Usually when applying a binary diff generated without --binary, it will be rejected early, as we don't even have the full sha1 of the pre- and post-images. However, if the diff is generated with --full-index (but not --binary), then we will actually try to apply it. If we have the postimage blob, then we can take a shortcut and never even look at the binary diff at all (e.g., this can happen when rebasing changes within a repository). If we don't have the postimage blob, though, we try to look at the actual fragments, of which there are none, and get a segfault. This patch checks explicitly for that case and complains to the user instead of segfaulting. We need to keep the check at a low level so that the "shortcut" case above continues to work. We also add a test that demonstrates the segfault. While we're at it, let's also explicitly test the shortcut case. Reported-by: Rafaël Carré <rafael.carre@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-13apply: Recognize epoch timestamps with : in the timezoneLibravatar Anders Kaseorg1-4/+7
Some patches have a timezone formatted like ‘-08:00’ instead of ‘-0800’ (e.g. http://lwn.net/Articles/131729/), so git apply would fail to recognize the epoch timestamp of deleted files and would create empty files instead. Teach it to support both formats, and add a test case. Signed-off-by: Anders Kaseorg <andersk@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-03Merge branch 'jn/apply-filename-with-sp'Libravatar Junio C Hamano1-38/+211
* jn/apply-filename-with-sp: apply: handle traditional patches with space in filename tests: exercise "git apply" with weird filenames apply: split quoted filename handling into new function
2010-08-31Merge branch 'jn/paginate-fix'Libravatar Junio C Hamano1-3/+3
* jn/paginate-fix: t7006 (pager): add missing TTY prerequisites merge-file: run setup_git_directory_gently() sooner var: run setup_git_directory_gently() sooner ls-remote: run setup_git_directory_gently() sooner index-pack: run setup_git_directory_gently() sooner config: run setup_git_directory_gently() sooner bundle: run setup_git_directory_gently() sooner apply: run setup_git_directory_gently() sooner grep: run setup_git_directory_gently() sooner shortlog: run setup_git_directory_gently() sooner git wrapper: allow setup_git_directory_gently() be called earlier setup: remember whether repository was found git wrapper: introduce startup_info struct Conflicts: builtin/index-pack.c
2010-08-21apply: handle traditional patches with space in filenameLibravatar Jonathan Nieder1-14/+179
To discover filenames from the --- and +++ lines in a traditional unified diff, currently "git apply" scans forward for a whitespace character on each line and stops there. It can't use the whole line because "diff -u" likes to include timestamps, like so: --- foo 2000-07-12 16:56:50.020000414 -0500 +++ bar 2010-07-12 16:56:50.020000414 -0500 The whitespace-seeking heuristic works great, even when the tab has been converted to spaces by some email + copy-and-paste related corruption. Except for one problem: if the filename itself contains whitespace, the inferred filename will be too short. When Giuseppe ran into this problem, it was for a file creation patch (for debian/licenses/LICENSE.global BSD-style Chromium). So one can't use the list of files present in the index to deduce an appropriate filename (not to mention that way lies madness; see v0.99~402, 2005-05-31). Instead, look for a timestamp and use that if present to mark the end of the filename. If no timestamp is present, the old heuristic is used, with one exception: the space character \040 is not considered terminating whitespace any more unless it is followed by a timestamp. Reported-by: Giuseppe Iuculano <iuculano@debian.org> Acked-by: Guido Günther <agx@sigxcpu.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-21apply: split quoted filename handling into new functionLibravatar Jonathan Nieder1-30/+38
The new find_name_gnu() function handles new-style '--- "a/foo"' patch header lines, leaving find_name() itself a bit less daunting. Functional change: do not clobber the p-value when there are not enough path components in a quoted file name to honor it. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-15apply: run setup_git_directory_gently() soonerLibravatar Nguyễn Thái Ngọc Duy1-3/+3
As v1.7.2~16^2 (2010-07-14) explains, without this change, “git --paginate apply” can ignore the repository-local “[core] pager” configuration. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-23Teach "apply --index-info" to handle rename patchesLibravatar Junio C Hamano1-2/+1
With v1.5.3.2~14 (apply --index-info: fall back to current index for mode changes, 2007-09-17), git apply learned to stop worrying about the lack of diff index line when a file already present in the current index had no content change. But it still worries too much: for rename patches, it is checking that both the old and new filename are present in the current index. This makes no sense, since a file rename generally involves creating a file there was none before. So just check the old filename. Noticed while trying to use “git rebase” with diff.renames = copies. [jn: add tests] Reported-by: David D. Kilzer <ddkilzer@kilzer.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-30Merge branch 'jp/string-list-api-cleanup'Libravatar Junio C Hamano1-5/+5
* jp/string-list-api-cleanup: string_list: Fix argument order for string_list_append string_list: Fix argument order for string_list_lookup string_list: Fix argument order for string_list_insert_at_index string_list: Fix argument order for string_list_insert string_list: Fix argument order for for_each_string_list string_list: Fix argument order for print_string_list
2010-06-27string_list: Fix argument order for string_list_appendLibravatar Julian Phillips1-1/+1
Update the definition and callers of string_list_append to use the string_list as the first argument. This helps make the string_list API easier to use by being more consistent. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-27string_list: Fix argument order for string_list_lookupLibravatar Julian Phillips1-1/+1
Update the definition and callers of string_list_lookup to use the string_list as the first argument. This helps make the string_list API easier to use by being more consistent. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-27string_list: Fix argument order for string_list_insertLibravatar Julian Phillips1-3/+3
Update the definition and callers of string_list_insert to use the string_list as the first argument. This helps make the string_list API easier to use by being more consistent. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-21Merge branch 'gv/portable'Libravatar Junio C Hamano1-2/+2
* gv/portable: test-lib: use DIFF definition from GIT-BUILD-OPTIONS build: propagate $DIFF to scripts Makefile: Tru64 portability fix Makefile: HP-UX 10.20 portability fixes Makefile: HPUX11 portability fixes Makefile: SunOS 5.6 portability fix inline declaration does not work on AIX Allow disabling "inline" Some platforms lack socklen_t type Make NO_{INET_NTOP,INET_PTON} configured independently Makefile: some platforms do not have hstrerror anywhere git-compat-util.h: some platforms with mmap() lack MAP_FAILED definition test_cmp: do not use "diff -u" on platforms that lack one fixup: do not unconditionally disable "diff -u" tests: use "test_cmp", not "diff", when verifying the result Do not use "diff" found on PATH while building and installing enums: omit trailing comma for portability Makefile: -lpthread may still be necessary when libc has only pthread stubs Rewrite dynamic structure initializations to runtime assignment Makefile: pass CPPFLAGS through to fllow customization Conflicts: Makefile wt-status.h
2010-05-31enums: omit trailing comma for portabilityLibravatar Gary V. Vaughan1-2/+2
Without this patch at least IBM VisualAge C 5.0 (I have 5.0.2) on AIX 5.1 fails to compile git. enum style is inconsistent already, with some enums declared on one line, some over 3 lines with the enum values all on the middle line, sometimes with 1 enum value per line... and independently of that the trailing comma is sometimes present and other times absent, often mixing with/without trailing comma styles in a single file, and sometimes in consecutive enum declarations. Clearly, omitting the comma is the more portable style, and this patch changes all enum declarations to use the portable omitted dangling comma style consistently. Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-08Merge branch 'bg/apply-blank-trailing-context'Libravatar Junio C Hamano1-6/+6
* bg/apply-blank-trailing-context: apply: Allow blank *trailing* context lines to match beyond EOF
2010-05-08Merge branch 'cw/ws-indent-with-tab'Libravatar Junio C Hamano1-42/+39
* cw/ws-indent-with-tab: whitespace: tests for git-apply --whitespace=fix with tab-in-indent whitespace: add tab-in-indent support for --whitespace=fix whitespace: replumb ws_fix_copy to take a strbuf *dst instead of char *dst whitespace: tests for git-diff --check with tab-in-indent error class whitespace: add tab-in-indent error class whitespace: we cannot "catch all errors known to git" anymore
2010-05-08Merge branch 'pc/remove-warn'Libravatar Junio C Hamano1-5/+1
* pc/remove-warn: Remove a redundant errno test in a usage of remove_path Introduce remove_or_warn function Implement the rmdir_or_warn function Generalise the unlink_or_warn function
2010-04-09Merge branch 'maint'Libravatar Junio C Hamano1-4/+1
* maint: Let check_preimage() use memset() to initialize "struct checkout" fetch/push: fix usage strings
2010-04-04whitespace: replumb ws_fix_copy to take a strbuf *dst instead of char *dstLibravatar Chris Webb1-42/+39
To implement --whitespace=fix for tab-in-indent, we have to allow for the possibility that whitespace can increase in size when it is fixed, expanding tabs to to multiple spaces in the initial indent. Signed-off-by: Chris Webb <chris@arachsys.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-28Introduce remove_or_warn functionLibravatar Peter Collingbourne1-5/+1
This patch introduces the remove_or_warn function which is a generalised version of the {unlink,rmdir}_or_warn functions. It takes an additional parameter indicating the mode of the file to be removed. The patch also modifies certain functions to use remove_or_warn where appropriate, and adds a test case for a bug fixed by the use of remove_or_warn. Signed-off-by: Peter Collingbourne <peter@pcc.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-20Merge branch 'bg/apply-fix-blank-at-eof'Libravatar Junio C Hamano1-40/+145
* bg/apply-fix-blank-at-eof: t3417: Add test cases for "rebase --whitespace=fix" t4124: Add additional tests of --whitespace=fix apply: Allow blank context lines to match beyond EOF apply: Remove the quick rejection test apply: Don't unnecessarily update line lengths in the preimage
2010-02-22Move 'builtin-*' into a 'builtin/' subdirectoryLibravatar Linus Torvalds1-0/+3670
This shrinks the top-level directory a bit, and makes it much more pleasant to use auto-completion on the thing. Instead of [torvalds@nehalem git]$ em buil<tab> Display all 180 possibilities? (y or n) [torvalds@nehalem git]$ em builtin-sh builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o [torvalds@nehalem git]$ em builtin-shor<tab> builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil<tab> [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh<tab> [type] shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o [torvalds@nehalem git]$ em builtin/sho [auto-completes to] [torvalds@nehalem git]$ em builtin/shor<tab> [type] shortlog.c shortlog.o [torvalds@nehalem git]$ em builtin/shortlog.c which doesn't seem all that different, but not having that annoying break in "Display all 180 possibilities?" is quite a relief. NOTE! If you do this in a clean tree (no object files etc), or using an editor that has auto-completion rules that ignores '*.o' files, you won't see that annoying 'Display all 180 possibilities?' message - it will just show the choices instead. I think bash has some cut-off around 100 choices or something. So the reason I see this is that I'm using an odd editory, and thus don't have the rules to cut down on auto-completion. But you can simulate that by using 'ls' instead, or something similar. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>