aboutsummaryrefslogtreecommitdiff
path: root/apply.c
Commit message (Collapse)AuthorAge
* fix potential deadlock in create_one_fileAlex Riesen2006-01-05
| | | | | | | | It can happen if the temporary file already exists (i.e. after a panic and reboot). Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* trivial: O_EXCL makes O_TRUNC redundantAlex Riesen2006-01-05
| | | | | Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* xread/xwrite: do not worry about EINTR at calling sites.Junio C Hamano2005-12-19
| | | | | | | | | | We had errno==EINTR check after read(2)/write(2) sprinkled all over the places, always doing continue. Consolidate them into xread()/xwrite() wrapper routines. Credits for suggestion goes to HPA -- bugs are mine. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-apply: work from subdirectory.Junio C Hamano2005-11-28
| | | | | | | | | | | When applying a patch to index file, we need to know where GIT_DIR is; use setup_git_directory() to find it out. This also allows us to work from a subdirectory if we wanted to. When git-apply is run from a subdirectory, it applies the given patch only to the files under the current directory and below. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Deal with binary diff output from GNU diff 2.8.7Junio C Hamano2005-11-17
| | | | | | | Some vintage of diff says just "Files X and Y differ\n", instead of "Binary files X and Y differ\n", so catch both patterns. Signed-off-by: Junio C Hamano <junkio@cox.net>
* apply: allow-binary-replacement.Junio C Hamano2005-11-16
| | | | | | | | | | | | | | | | A new option, --allow-binary-replacement, is introduced. When you feed a diff that records full SHA1 name of pre- and post-image blob on its index line to git-apply with this option, the post-image blob replaces the path if what you have in the working tree matches the pre-image _and_ post-image blob is already available in the object directory. Later we _might_ want to enhance the diff output to also include the full binary data of the post-image, to make this more useful, but this is good enough for local rebasing application. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-apply: fail if a patch cannot be applied.Junio C Hamano2005-11-16
| | | | | | | | | | Recently we fixed 'git-apply --stat' not to barf on a binary differences. But it accidentally broke the error detection when we actually attempt to apply them. This commit fixes the problem and adds test cases. Signed-off-by: Junio C Hamano <junkio@cox.net>
* apply: fix binary patch detection.Junio C Hamano2005-11-14
| | | | | | | | | | The comparison to find "Binary files " string was looking at a wrong place when offset != 0. Also, we may have the full 40-byte textual sha1 on the index line; two off-by-one errors prevented it. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Documentation: git-apply --no-addJunio C Hamano2005-11-11
| | | | | | | This is a specialized hack to help no-base merges, but other people might find it useful, so let's document it. Signed-off-by: Junio C Hamano <junkio@cox.net>
* merge-one-file: use common as base, instead of emptiness.Junio C Hamano2005-11-11
| | | | | | | | | | | | | | | | | | | | | Unlike the previous round that merged the path added differently in each branches using emptiness as the base, compute a common version and use it as input to 'merge' program. This would show the resulting (still conflicting) file left in the working tree as: common file contents... <<<<<< FILENAME version from our branch... ====== version from their branch... >>>>>> .merge_file_XXXXXX more common file contents... when both sides added similar contents. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-apply: do not fail on binary diff when not applying nor checking.Junio C Hamano2005-11-09
| | | | | | | | | | | We run git-apply with --stat and --summary at the end of the pull by default, which causes it to barf when the pull brought in changes to binary files. Just mark them as binary patch and proceed when not applying nor checking. [jc: I almost missed --check until I saw Linus did something similar.] Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-apply --numstatJunio C Hamano2005-10-28
| | | | | | | | | The new option, --numstat, shows number of inserted and deleted lines for each path. It is similar to --stat output but is meant to be more machine friendly by giving number of added and deleted lines and unabbreviated paths. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-apply: remove unused --show-files flag.Junio C Hamano2005-10-17
| | | | | | | Linus says he does not use it (and the thinking behind its initial introduction), and neither Cogito nor StGIT uses it. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Update git-apply to use C-style quoting for funny pathnames.Junio C Hamano2005-10-17
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* Unlocalized isspace and friendsLinus Torvalds2005-10-14
| | | | | | | | | Do our own ctype.h, just to get the sane semantics: we want locale-independence, _and_ we want the right signed behaviour. Plus we only use a very small subset of ctype.h anyway (isspace, isalpha, isdigit and isalnum). Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-apply: parse index informationJunio C Hamano2005-10-07
| | | | | | | | | | | | | Add an new option --show-index-info to git-apply command to summarize the index information new git-diff outputs. The command shows something similar to git-ls-files --stage output for the pre-change image: 100644 7be5041... apply.c 100644 ec2a161... cache.h ... Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-apply: retire unused/unimplemented --no-merge flag.Junio C Hamano2005-10-04
| | | | | | | | The original plan was to do 3-way merge between local working tree, index and the patch being applied, but that was never implemented. Retire the flag to control its behaviour. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-apply: allow operating in sparsely populated working tree.Junio C Hamano2005-10-04
| | | | | | | | This patch teaches 'git-apply --index' to automatically check out a file being patched. This happens only when the working tree does not have it checked out. Signed-off-by: Junio C Hamano <junkio@cox.net>
* [PATCH] Flag empty patches as errorsLinus Torvalds2005-09-30
| | | | | | | | | | | | | | | | | | | | | | | A patch that contains no actual diff, and that doesn't change any meta-data is bad. It shouldn't be a patch at all, and git-apply shouldn't just accept it. This caused a corrupted patch to be silently applied as an empty change in the kernel, because the corruption ended up making the patch look empty. An example of such a patch is one that contains the patch header, but where the initial fragment header (the "@@ -nr,.." line) is missing, causing us to not parse any fragments. The real "patch" program will also flag such patches as bad, with the message patch: **** Only garbage was found in the patch input. and we should do likewise. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* [PATCH] Make git-apply understand incomplete lines in non-C localesFredrik Kuivinen2005-09-04
| | | | | | | | | | | | | | | | | | | | | | | | The message "\ No newline at end of file" used by diff(1) to mark an incomplete line is locale dependent. We can't assume more than that it begins with "\ ". For example, given two files, "foo" and "bar", with appropriate contents, 'diff -u foo bar' will produce the following output on my system: --- foo 2005-09-04 18:59:38.000000000 +0200 +++ bar 2005-09-04 18:59:16.000000000 +0200 @@ -1 +1 @@ -foobar +foo \ Ingen nyrad vid filslut [jc: the check for the marker still uses the line length being no less than 12 bytes for a sanity check, but I think it is safe to assume that in other locales. I haven't checked the .po files from diff, tho'.] Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge refs/heads/portable from http://www.cs.berkeley.edu/~ejr/gits/git.git Junio C Hamano2005-08-28
|\
| * Fix ?: statements.Jason Riedy2005-08-23
| | | | | | | | | | | | | | | | | | Omitting the first branch in ?: is a GNU extension. Cute, but not supported by other compilers. Replaced mostly by explicit tests. Calls to getenv() simply are repeated on non-GNU compilers. Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
* | [PATCH] Fix git patch header processing in git-apply.Robert Fitzsimons2005-08-28
|/ | | | | | | | Stop processing and return NULL if we encounter a '\n' character before we have two matching names in the git header. Signed-off-by: Robert Fitzsimons <robfitz@273k.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* [PATCH] When copying or renaming, keep the mode, pleaseJohannes Schindelin2005-08-17
| | | | | | | | | | | Without this patch, git-apply does not retain the mode when renaming or copying files. [jc: Good catch, Johannes. I added a test case to demonstrate the breackage in the original.] Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
* [PATCH] -Werror fixesTimo Sirainen2005-08-09
| | | | | | GCC's format __attribute__ is good for checking errors, especially with -Wformat=2 parameter. This fixes most of the reported problems against 2005-08-09 snapshot.
* [PATCH] Make git-apply --stat less butt-ugly with long filenamesLinus Torvalds2005-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When git-apply was printing out long filenames, it used to just truncate them to show the last "max_len" characters of the filename. Which can be really quite ugly (note the two filenames that have just been silently truncated from the beginning - it looks even worse when there are lots of them, like there were in the current v2.6.13-rc4 cris arch update): Documentation/video4linux/README.saa7134 | 9 Documentation/video4linux/bttv/Cards | 74 umentation/video4linux/hauppauge-wintv-cx88-ir.txt | 54 Documentation/video4linux/lifeview.txt | 42 mentation/video4linux/not-in-cx2388x-datasheet.txt | 41 Documentation/w1/w1.generic | 107 With this patch it now looks like so: Documentation/video4linux/README.saa7134 | 9 Documentation/video4linux/bttv/Cards | 74 .../video4linux/hauppauge-wintv-cx88-ir.txt | 54 Documentation/video4linux/lifeview.txt | 42 .../video4linux/not-in-cx2388x-datasheet.txt | 41 Documentation/w1/w1.generic | 107 ie we've made it clear with an ellipsis that we've cut off something from the beginning, and it also tries to do it cleanly at a subdirectory level. Signed-off-by: Linus "good taste" Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* [PATCH] apply.c: --exclude=fnmatch-pattern option.Junio C Hamano2005-07-22
| | | | | | | | | | Adds --exclude=pattern option to the "git-apply" command. This was useful while reimporting the BKCVS patchset dump of the Linux kernel, starting at 2.4.0 and ending at 2.6.12-rc2 Ingo announced some time ago to exclude BitKeeper directory. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] apply.c: handle incomplete lines correctly.Junio C Hamano2005-07-22
| | | | | | | | | | | | | The parsing code had a bug that failed to recognize an incomplete line at the end of a fragment, and the fragment application code had a comparison bug to recognize such. Fix them to handle incomplete lines correctly. Add a test script for patches with various combinations of complete and incomplete lines to make sure the fix works. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] apply: match documentation, usage string and code.Junio C Hamano2005-07-13
| | | | | | | The more recent --apply option was not described. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* git-apply: be a lot more careful when writing filesLinus Torvalds2005-07-13
| | | | | | | | | | We write them under another name and rename them to their destination, so that if something bad happens in the middle, we won't have caused any bigger harm. Also, this makes the writing be NFS "intr" safe, and as a side effects makes sure that if the target is hardlinked (or symlinked) we will have broken the link.
* [PATCH] git: fix trivial warning from show_rename_copy()Tony Luck2005-07-12
| | | | | | | | apply.c: In function `show_rename_copy': apply.c:1147: warning: field precision is not type int (arg 3) Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Let umask do its work upon filesystem object creation.Junio C Hamano2005-07-06
| | | | | | | | IIRC our strategy was to let the users' umask take care of the final mode bits. This patch fixes places that deviate from it. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Fix sparse warnings.Linus Torvalds2005-07-03
| | | | | Mainly making a lot of local functions and variables be marked "static", but there was a "zero as NULL" warning in there too.
* git-apply: take "--apply" flag to force an apply even if we also ask for a ↵Linus Torvalds2005-06-23
| | | | | | diffstat Also, remove debugging statement about applying a fragment at an offset.
* [PATCH] git-apply: implement --summary option.Junio C Hamano2005-06-22
| | | | | | | | | Typical expected usage is "git-apply --stat --summary" to show diffstat plus dense description of information available in git extended headers, such as creations, renames, and mode changes. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] git-apply --stat: show new filename for rename/copy patch.Junio C Hamano2005-06-22
| | | | | | | | | | When a patch is a git extended rename/copy patch, "git-apply --stat" showed the old filename. Change it to show the new filename, because most of the time we are interested in looking at the resulting tree. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* git-apply: create subdirectories leading up to a new fileLinus Torvalds2005-06-21
| | | | | | | Applying Andrew's latest patch-bomb showed us failing miserably if a new subdirectory needed to be created.. That said, it's uncommon enough that it's worth optimistically assuming it won't be needed, and then creating the subdirectories only on failure.
* [PATCH] git-apply: Don't barf when --stat'ing a diff with no line changes.Sven Verdoolaege2005-06-21
| | | | | | | | | Diffs with only mode changes didn't pass through git-apply --stat. [ Linus' note: they did for me, on my ppc64, where division by zero just silently returns zero. Duh. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* git-apply: use default name for mode change patchesLinus Torvalds2005-06-17
| | | | | | Pure mode changes won't have the file-name in the extended header lines, so make sure we pick it up from the default name from the "diff --git" line.
* git-apply: normalize file mode when comparing with expected valueLinus Torvalds2005-06-13
| | | | | Sine git only saves the 'x' bit, we shouldn't compare the stat contents directly.
* git-apply: fix error handling for nonexistent filesLinus Torvalds2005-06-12
| | | | | Missing argument for error() function. We should really use the gcc printf format checking capabilities.
* git-apply: ignore empty git headersLinus Torvalds2005-06-12
| | | | | | | | | | | A meaningful (ie non-empty) git patch always has more information in the header than just the "diff --git" line itself: it needs to have either a patch associated with it (which implies "---" and "+++" lines in the header) or it needs to have rename/copy/delete/create information in it. Just ignore git patches which have no change information. Otherwise we'll end up with a patch that doesn't have filenames etc filled in, and we'll be unhappy.
* git-apply: creatign empty files is nonfatalLinus Torvalds2005-06-08
| | | | (but it will result in a warning)
* diff 'rename' format change.Linus Torvalds2005-06-05
| | | | | | | | | Clearly even Junio felt git "rename" header lines should say "from/to" instead of "old/new", since he wrote the documentation that way. This way it also matches "copy". git-apply will accept both versions, at least for a while.
* git-apply: consider it an error to apply no changesLinus Torvalds2005-06-05
| | | | | | A "--stat" or a "--check" will just be quiet, but if you try to apply something with no changes, that's an error.
* git-apply: fix rename header parsingLinus Torvalds2005-06-05
| | | | | | | It's not "rename from" and "rename to", it's "rename old" and "rename new". Which is illogical and doesn't match the "copy from/to" case, but that's life. Maybe Junio will fix it up one of these days.
* git-apply: actually apply patches and update the indexLinus Torvalds2005-06-05
| | | | | | | | | | We update the index only if the "--index" flag is given, so you can actually use this as a strange kind of "patch" program even for non-git usage. Not that you'd likely want to, but it comes in handy for testing. This _should_ more or less get everythign right, but as usual I leave the testing to the usrs..
* git-apply: fix apply of a new fileLinus Torvalds2005-06-05
| | | | | (And fix name handling for when we have an implied create or delete event from a traditional diff).
* git-apply: find offset fragments, and really apply themLinus Torvalds2005-06-05
| | | | | | | This applies the fragments in memory, but doesn't actually write the results out to the files yet. But we now do all the difficult parts, the rest is just basically writing the results out and updating the index.
* git-apply: first cut at actually checking fragment dataLinus Torvalds2005-06-05
| | | | | | | | Right now it requires that the fragment offsets be exact, and it doesn't actually apply the fragment yet, but it does find where it goes and verify the data. Next step: actually applying the fragment changes.
generated by cgit v1.2.1 (git 2.18.0) at 2024-11-04 02:13:33 +0000