summaryrefslogtreecommitdiff
path: root/builtin/apply.c
AgeCommit message (Collapse)AuthorFilesLines
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-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-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>