summaryrefslogtreecommitdiff
path: root/builtin-apply.c
AgeCommit message (Collapse)AuthorFilesLines
2007-09-20Full rework of quote_c_style and write_name_quoted.Libravatar Pierre Habouzit1-47/+30
* quote_c_style works on a strbuf instead of a wild buffer. * quote_c_style is now clever enough to not add double quotes if not needed. * write_name_quoted inherits those advantages, but also take a different set of arguments. Now instead of asking for quotes or not, you pass a "terminator". If it's \0 then we assume you don't want to escape, else C escaping is performed. In any case, the terminator is also appended to the stream. It also no longer takes the prefix/prefix_len arguments, as it's seldomly used, and makes some optimizations harder. * write_name_quotedpfx is created to work like write_name_quoted and take the prefix/prefix_len arguments. Thanks to those API changes, diff.c has somehow lost weight, thanks to the removal of functions that were wrappers around the old write_name_quoted trying to give it a semantics like the new one, but performing a lot of allocations for this goal. Now we always write directly to the stream, no intermediate allocation is performed. As a side effect of the refactor in builtin-apply.c, the length of the bar graphs in diffstats are not affected anymore by the fact that the path was clipped. Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-20Rework unquote_c_style to work on a strbuf.Libravatar Pierre Habouzit1-61/+62
If the gain is not obvious in the diffstat, the resulting code is more readable, _and_ in checkout-index/update-index we now reuse the same buffer to unquote strings instead of always freeing/mallocing. This also is more coherent with the next patch that reworks quoting functions. The quoting function is also made more efficient scanning for backslashes and treating portions of strings without a backslash at once. Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-19builtin-apply.c: fix a tiny leak introduced during xmemdupz() conversion.Libravatar Junio C Hamano1-0/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-18Use xmemdupz() in many places.Libravatar Pierre Habouzit1-9/+2
Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-18Merge branch 'master' into ph/strbufLibravatar Junio C Hamano1-8/+35
* master: (94 commits) Fixed update-hook example allow-users format. Documentation/git-svn: updated design philosophy notes t/t4014: test "am -3" with mode-only change. git-commit.sh: Shell script cleanup preserve executable bits in zip archives Fix lapsus in builtin-apply.c git-push: documentation and tests for pushing only branches git-svnimport: Use separate arguments in the pipe for git-rev-parse contrib/fast-import: add perl version of simple example contrib/fast-import: add simple shell example rev-list --bisect: Bisection "distance" clean up. rev-list --bisect: Move some bisection code into best_bisection. rev-list --bisect: Move finding bisection into do_find_bisection. Document ls-files --with-tree=<tree-ish> git-commit: partial commit of paths only removed from the index git-commit: Allow partial commit of file removal. send-email: make message-id generation a bit more robust git-apply: fix whitespace stripping git-gui: Disable native platform text selection in "lists" apply --index-info: fall back to current index for mode changes ...
2007-09-18Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: Fixed update-hook example allow-users format. Documentation/git-svn: updated design philosophy notes t/t4014: test "am -3" with mode-only change. Fix lapsus in builtin-apply.c git-push: documentation and tests for pushing only branches git-svnimport: Use separate arguments in the pipe for git-rev-parse
2007-09-18Fix lapsus in builtin-apply.cLibravatar Pierre Habouzit1-1/+1
Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-18Merge branch 'cr/reset'Libravatar Junio C Hamano1-2/+0
* cr/reset: Simplify cache API An additional test for "git-reset -- path" Make "git reset" a builtin. Move make_cache_entry() from merge-recursive.c into read-cache.c Add tests for documented features of "git reset".
2007-09-17git-apply: fix whitespace strippingLibravatar J. Bruce Fields1-3/+10
The algorithm isn't right here: it accumulates any set of 8 spaces into tabs even if they're separated by tabs, so <four spaces><tab><four spaces><tab> is converted to <tab><tab><tab> when it should be just <tab><tab> So teach git-apply that a tab hides any group of less than 8 previous spaces in a row. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-16apply --index-info: fall back to current index for mode changesLibravatar Johannes Schindelin1-2/+24
"git diff" does not record index lines for pure mode changes (i.e. no lines changed). Therefore, apply --index-info would call out a bogus error. Instead, fall back to reading the info from the current index. Incidentally, this fixes an error where git-rebase would not rebase a commit including a pure mode change, and changes requiring a threeway merge. Noticed and later tested by Chris Shoemaker. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-16builtin-apply: use strbuf's instead of buffer_desc's.Libravatar Pierre Habouzit1-140/+72
Signed-off-by: Pierre Habouzit <madcoder@debian.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-16Now that cache.h needs strbuf.h, remove useless includes.Libravatar Pierre Habouzit1-1/+0
Signed-off-by: Pierre Habouzit <madcoder@debian.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-16Rewrite convert_to_{git,working_tree} to use strbuf's.Libravatar Pierre Habouzit1-14/+13
* Now, those functions take an "out" strbuf argument, where they store their result if any. In that case, it also returns 1, else it returns 0. * those functions support "in place" editing, in the sense that it's OK to call them this way: convert_to_git(path, sb->buf, sb->len, sb); When doable, conversions are done in place for real, else the strbuf content is just replaced with the new one, transparentely for the caller. If you want to create a new filter working this way, being the accumulation of filter1, filter2, ... filtern, then your meta_filter would be: int meta_filter(..., const char *src, size_t len, struct strbuf *sb) { int ret = 0; ret |= filter1(...., src, len, sb); if (ret) { src = sb->buf; len = sb->len; } ret |= filter2(...., src, len, sb); if (ret) { src = sb->buf; len = sb->len; } .... return ret | filtern(..., src, len, sb); } That's why subfilters the convert_to_* functions called were also rewritten to work this way. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-14Simplify cache APILibravatar Junio C Hamano1-2/+0
Earlier, add_file_to_index() invalidated the path in the cache-tree but remove_file_from_cache() did not, and the user of the latter needed to invalidate the entry himself. This led to a few bugs due to missed invalidate calls already. This patch makes the management of cache-tree less error prone by making more invalidate calls from lower level cache API functions. The rules are: - If you are going to write the index, you should either maintain cache_tree correctly. - If you cannot, alternatively you can remove the entire cache_tree by calling cache_tree_free() before you call write_cache(). - When you modify the index, cache_tree_invalidate_path() should be called with the path you are modifying, to discard the entry from the cache-tree structure. - The following cache API functions exported from read-cache.c (and the macro whose names have "cache" instead of "index") automatically call cache_tree_invalidate_path() for you: - remove_file_from_index(); - add_file_to_index(); - add_index_entry(); You can modify the index bypassing the above API functions (e.g. find an existing cache entry from the index and modify it in place). You need to call cache_tree_invalidate_path() yourself in such a case. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-10Strbuf API extensions and fixes.Libravatar Pierre Habouzit1-2/+2
* Add strbuf_rtrim to remove trailing spaces. * Add strbuf_insert to insert data at a given position. * Off-by one fix in strbuf_addf: strbuf_avail() does not counts the final \0 so the overflow test for snprintf is the strict comparison. This is not critical as the growth mechanism chosen will always allocate _more_ memory than asked, so the second test will not fail. It's some kind of miracle though. * Add size extension hints for strbuf_init and strbuf_read. If 0, default applies, else: + initial buffer has the given size for strbuf_init. + first growth checks it has at least this size rather than the default 8192. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-06Use strbuf API in apply, blame, commit-tree and diffLibravatar Pierre Habouzit1-21/+9
Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-05git-apply: do not read past the end of bufferLibravatar Junio C Hamano1-1/+2
When the preimage we are patching is shorter than what the patch text expects, we tried to match the buffer contents at the "original" line with the fragment in full, without checking we have enough data to match in the preimage. This caused the size of a later memmove() to wrap around and attempt to scribble almost the entire address space. Not good. The code that follows the part this patch touches tries to match the fragment with line offsets. Curiously, that code does not have the problem --- it guards against reading past the end of the preimage. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-15git-apply: apply submodule changesLibravatar Sven Verdoolaege1-25/+86
Apply "Subproject commit HEX" changes produced by git-diff. As usual in the current git, only the superproject itself is actually modified (possibly creating empty directories for new submodules). Any checked-out submodule is left untouched and is not required to be up-to-date. With clean-ups from Junio C Hamano. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-06Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: apply: remove directory that becomes empty by renaming the last file away setup.c:verify_non_filename(): don't die unnecessarily while disambiguating
2007-08-06apply: remove directory that becomes empty by renaming the last file awayLibravatar Linus Torvalds1-1/+1
We attempt to remove directory that becomes empty after removal of a file. We should do the same when we rename an existing file away. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-07Merge branch 'maint'Libravatar Junio C Hamano1-1/+5
* maint: Fix "apply --reverse" with regard to whitespace
2007-07-07Fix "apply --reverse" with regard to whitespaceLibravatar Johannes Schindelin1-1/+5
"git apply" used to take check the whitespace in the wrong direction. Noticed by Daniel Barkalow. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-02git-apply: what is detected and fixed is not just trailing spaces.Libravatar Junio C Hamano1-9/+8
But we kept saying "trailing whitespace" all the same. Reword the error messages a bit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-20git-apply: Fix removal of new trailing blank lines.Libravatar Junio C Hamano1-33/+15
The earlier code removed one newline too many from the hunk that adds new lines at the end of the file. Also the way the code counted the added blank lines was somewhat roundabout; I think the way updated code does it is more direct and easier to follow: * We keep track of the number of blank lines added; * While processing each line, we notice if it adds a blank line, and increment the counter, or reset it to zero otherwise; * When actually we apply the data, we remove the empty lines we counted earlier if we are applying it at the end of the file. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-20Teach 'git-apply --whitespace=strip' to remove empty lines at the end of fileLibravatar Marco Costalba1-3/+40
[jc: with an obvious microfix to avoid doing this unless --whitespace=strip] Signed-off-by: Marco Costalba <mcostalba@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-15Ensure return value from xread() is always stored into an ssize_tLibravatar Johan Herland1-2/+2
This patch fixes all calls to xread() where the return value is not stored into an ssize_t. The patch should not have any effect whatsoever, other than putting better/more appropriate type names on variables. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-11apply: do not get confused by symlinks in the middleLibravatar Junio C Hamano1-9/+26
HPA noticed that git-rebase fails when changes involve symlinks in the middle of the hierarchy. Consider: * The tree state before the patch is applied has arch/x86_64/boot as a symlink pointing at ../i386/boot/ * The patch tries to remove arch/x86_64/boot symlink, and create bunch of files there: .gitignore, Makefile, etc. git-apply tries to be careful while applying patches; it never touches the working tree until it is convinced that the patch would apply cleanly. One of the check it does is that when it knows a path is going to be created by the patch, it runs lstat() on the path to make sure it does not exist. This leads to a false alarm. Because we do not touch the working tree before all the check passes, when we try to make sure that arch/x86_64/boot/.gitignore does not exist yet, we haven't removed the arch/x86_64/boot symlink. The lstat() check ends up seeing arch/i386/boot/.gitignore through the yet-to-be-removed symlink, and says "Hey, you already have a file there, but what you fed me is a patch to create a new file. I am not going to clobber what you have in the working tree." We have similar checks to see a file we are going to modify does exist and match the preimage of the diff, which is done by directly opening and reading the file. For a file we are going to delete, we make sure that it does exist and matches what is going to be removed (a removal patch records the full preimage, so we check what you have in your working tree matches it in full -- otherwise we would risk losing your local changes), which again is done by directly opening and reading the file. These checks need to be adjusted so that they are not fooled by symlinks in the middle. - To make sure something does not exist, first lstat(). If it does not exist, it does not, so be happy. If it _does_, we might be getting fooled by a symlink in the middle, so break leading paths and see if there are symlinks involved. When we are checking for a path a/b/c/d, if any of a, a/b, a/b/c is a symlink, then a/b/c/d does _NOT_ exist, for the purpose of our test. This would fix this particular case you saw, and would not add extra overhead in the usual case. - To make sure something already exists, first lstat(). If it does not exist, barf (up to this, we already do). Even if it does seem to exist, we might be getting fooled by a symlink in the middle, so make sure leading paths are not symlinks. This would make the normal codepath much more expensive for deep trees, which is a bit worrisome. This patch implements the first side of the check "making sure it does not exist". The latter "making sure it exists" check is not done yet, so applying the patch in reverse would still fail, but we have to start from somewhere. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-21Merge branch 'jc/attr'Libravatar Junio C Hamano1-11/+7
* 'jc/attr': (28 commits) lockfile: record the primary process. convert.c: restructure the attribute checking part. Fix bogus linked-list management for user defined merge drivers. Simplify calling of CR/LF conversion routines Document gitattributes(5) Update 'crlf' attribute semantics. Documentation: support manual section (5) - file formats. Simplify code to find recursive merge driver. Counto-fix in merge-recursive Fix funny types used in attribute value representation Allow low-level driver to specify different behaviour during internal merge. Custom low-level merge driver: change the configuration scheme. Allow the default low-level merge driver to be configured. Custom low-level merge driver support. Add a demonstration/test of customized merge. Allow specifying specialized merge-backend per path. merge-recursive: separate out xdl_merge() interface. Allow more than true/false to attributes. Document git-check-attr Change attribute negation marker from '!' to '-'. ...
2007-04-20Simplify calling of CR/LF conversion routinesLibravatar Alex Riesen1-11/+7
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-18Merge branch 'maint'Libravatar Junio C Hamano1-2/+1
* maint: git-shortlog: Fix two formatting errors in asciidoc documentation Fix overwriting of files when applying contextually independent diffs git-svn: don't allow globs to match regular files
2007-04-18Fix overwriting of files when applying contextually independent diffsLibravatar Alex Riesen1-2/+1
Noticed by applying two diffs of different contexts to the same file. The check for existence of a file was wrong: the test assumed it was a directory and reset the errno (twice: directly and by calling lstat). So if an entry existed and was _not_ a directory no attempt was made to rename into it, because the errno (expected by renaming code) was already reset to 0. This resulted in error: fatal: unable to write file file mode 100644 For Linux, removing "errno = 0" is enough, as lstat wont modify errno if it was successful. The behavior should not be depended upon, though, so modify the "if" as well. The test simulates this situation. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-07Merge branch 'jc/index-output'Libravatar Junio C Hamano1-3/+3
* jc/index-output: git-read-tree --index-output=<file> _GIT_INDEX_OUTPUT: allow plumbing to output to an alternative index file. Conflicts: builtin-apply.c
2007-04-05Merge branch 'maint'Libravatar Junio C Hamano1-2/+2
* maint: Fix lseek(2) calls with args 2 and 3 swapped Honor -p<n> when applying git diffs Fix dependency of common-cmds.h Fix renaming branch without config file DESTDIR support for git/contrib/emacs gitweb: Fix bug in "blobdiff" view for split (e.g. file to symlink) patches Document --left-right option to rev-list. Revert "builtin-archive: use RUN_SETUP" rename contrib/hooks/post-receieve-email to contrib/hooks/post-receive-email. rerere: make sorting really stable. Fix t4200-rerere for white-space from "wc -l"
2007-04-05Rename static variable write_index to update_index in builtin-apply.cLibravatar Junio C Hamano1-6/+6
This is an internal variable used to tell if we need to write out the resulting index. I'll be introducing write_index() function which would collide with it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-05Honor -p<n> when applying git diffsLibravatar Shawn O. Pearce1-2/+2
If the user is trying to apply a Git generated diff file and they have specified a -p<n> option, where <n> is not 1, the user probably has a good reason for doing this. Such as they are me, trying to apply a patch generated in git.git for the git-gui subdirectory to the git-gui.git repository, where there is no git-gui subdirectory present. Users shouldn't supply -p2 unless they mean it. But if they are supplying it, they probably have thought about how to make this patch apply to their working directory, and want to risk whatever results may come from that. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-03_GIT_INDEX_OUTPUT: allow plumbing to output to an alternative index file.Libravatar Junio C Hamano1-3/+3
When defined, this allows plumbing commands that update the index (add, apply, checkout-index, merge-recursive, mv, read-tree, rm, update-index, and write-tree) to write their resulting index to an alternative index file while holding a lock to the original index file. With this, git-commit that jumps the index does not have to make an extra copy of the index file, and more importantly, it can do the update while holding the lock on the index. However, I think the interface to let an environment variable specify the output is a mistake, as shown in the documentation. If a curious user has the environment variable set to something other than the file GIT_INDEX_FILE points at, almost everything will break. This should instead be a command line parameter to tell these plumbing commands to write the result in the named file, to prevent stupid mistakes. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-22git-apply: Do not free the wrong buffer when we convert the data for writeoutLibravatar Junio C Hamano1-7/+10
When we write out the result of patch application, we sometimes need to munge the data (e.g. under core.autocrlf). After doing so, what we should free is the temporary buffer that holds the converted data returned from convert_to_working_tree(), not the original one. This patch also moves the call to open() up in the function, as the caller expects us to fail cheaply if leading directories need to be created (and then the caller creates them and calls us again). For that calling pattern, attempting conversion before opening the file adds unnecessary overhead. Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07Cast 64 bit off_t to 32 bit size_tLibravatar Shawn O. Pearce1-1/+1
Some systems have sizeof(off_t) == 8 while sizeof(size_t) == 4. This implies that we are able to access and work on files whose maximum length is around 2^63-1 bytes, but we can only malloc or mmap somewhat less than 2^32-1 bytes of memory. On such a system an implicit conversion of off_t to size_t can cause the size_t to wrap, resulting in unexpected and exciting behavior. Right now we are working around all gcc warnings generated by the -Wshorten-64-to-32 option by passing the off_t through xsize_t(). In the future we should make xsize_t on such problematic platforms detect the wrapping and die if such a file is accessed. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-02Add core.symlinks to mark filesystems that do not support symbolic links.Libravatar Johannes Sixt1-1/+1
Some file systems that can host git repositories and their working copies do not support symbolic links. But then if the repository contains a symbolic link, it is impossible to check out the working copy. This patch enables partial support of symbolic links so that it is possible to check out a working copy on such a file system. A new flag core.symlinks (which is true by default) can be set to false to indicate that the filesystem does not support symbolic links. In this case, symbolic links that exist in the trees are checked out as small plain files, and checking in modifications of these files preserve the symlink property in the database (as long as an entry exists in the index). Of course, this does not magically make symbolic links work on such defective file systems; hence, this solution does not help if the working copy relies on that an entry is a real symbolic link. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-27convert object type handling from a string to a numberLibravatar Nicolas Pitre1-4/+4
We currently have two parallel notation for dealing with object types in the code: a string and a numerical value. One of them is obviously redundent, and the most used one requires more stack space and a bunch of strcmp() all over the place. This is an initial step for the removal of the version using a char array found in object reading code paths. The patch is unfortunately large but there is no sane way to split it in smaller parts without breaking the system. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-27Merge branch 'maint'Libravatar Junio C Hamano1-1/+2
* maint: git-apply: do not fix whitespaces on context lines. diff --cc: integer overflow given a 2GB-or-larger file mailinfo: do not get confused with logical lines that are too long.
2007-02-27git-apply: do not fix whitespaces on context lines.Libravatar Junio C Hamano1-1/+2
Internal function apply_line() is called to copy both context lines and added lines to the output buffer, while possibly fixing the whitespace breakages depending on --whitespace=strip settings. However, it did its fix-up on both context lines and added lines. This resulted in two symptoms: (1) The number of lines reported to have been fixed up included these context lines. (2) However, the lines actually shown were limited to the added lines that had whitespace breakages. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-24Merge branch 'js/apply'Libravatar Junio C Hamano1-1/+6
* js/apply: apply: make --verbose a little more useful
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-22apply: make --verbose a little more usefulLibravatar Johannes Schindelin1-1/+6
When a patch fails, I automatically add '-v' to the command line to see what fails. This patch makes -v a synonym to --verbose, and actually tells the user which text was not found. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
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>