aboutsummaryrefslogtreecommitdiff
path: root/apply.c
Commit message (Collapse)AuthorAge
* 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.
* git-apply --stat: limit lines to 79 charactersLinus Torvalds2005-05-31
| | | | | | It had already tried to do that, but with the independent rounding of the number of '+' and '-' characters, it would sometimes do 80-char lines after all.
* git-apply: don't try to be clever about filenames and the indexLinus Torvalds2005-05-31
| | | | | | It just causes things like "git-apply --stat" to parse traditional patch headers differently depending on what your index is, which is nasty.
* [PATCH] Show dissimilarity index for D and N case.Junio C Hamano2005-05-30
| | | | | | | | | | | | The way broken deletes and creates are shown in the -p (diff-patch) output format has become consistent with how rename/copy edits are shown. They will show "dissimilarity index" value, immediately following the "deleted file mode" and "new file mode" lines. The git-apply is taught to grok such an extended header. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-apply: add "--check" option to check that the diff makes senseLinus Torvalds2005-05-26
| | | | | It currently only verifies the index against the working directory, it doesn't actually verify the diff fragments themselves yet.
* git-apply: when validating default names, check the final EOLN tooLinus Torvalds2005-05-26
| | | | | This means that filenames are totally unambiguous even if they have spaces or tabs in them.
* git-apply: pick up default filenames from "diff --git" header lineLinus Torvalds2005-05-26
| | | | | Pure mode changes, and deletes or creates of empty files won't have this information anywhere else.
* git-apply: make the diffstat output happen for "--stat" only.Linus Torvalds2005-05-26
| | | | | | Slowly this is takign the form of a program that we'd actually use. Now "git-apply --stat" basically ends up being a perfectly useful diffstat.
* git-apply: implement "diffstat" outputLinus Torvalds2005-05-26
| | | | | Hey, it's almost free by now, and it's a good way to see that we parse the patches correctly.
* git-apply: parse the whole list of patches into memory firstLinus Torvalds2005-05-26
| | | | | | | | | | Make it a clear two-phase thing: first a read-only parse of the patch itself (which is independent of any current index information), and then the second phase actually uses the patch. The second phase might not be a real apply, it could be just a diffstat, for example. Which is trivial to do once the patch is parsed.
* [PATCH] Squelch compiler warningJunio C Hamano2005-05-24
| | | | | | | Not important but I am a bit annoyed by gcc complaining about the control falling out of the function without returning value. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* git-apply: more consistency checks on gitdiff filenamesLinus Torvalds2005-05-23
| | | | | | There's some duplication of filenames when doing filename operations (creates, deletes, renames and copies), and this makes us verify that the pathnames match when they should.
* git-apply: start using the index file information.Linus Torvalds2005-05-23
| | | | | Right now we only use it to figure out what the filename might be when that is ambiguous, but we'll get there..
* git-apply: if no input files specified, apply stdinLinus Torvalds2005-05-23
| | | | This makes it act more like a traditional UNIX thing (eg "cat").
* git-apply: unknown modes are zero, not -1Linus Torvalds2005-05-23
|
* git-apply: parse the diff headers (both traditional and new)Linus Torvalds2005-05-23
| | | | | | | | | .. and print out the information. This sets up all the pathname information, and whether it's a new file, deleted file, rename, copy or whatever. It's slowly getting to the point where it all comes together, and we can actually apply all the information that we've gathered.
* git-apply: improve error detection and messagesLinus Torvalds2005-05-23
| | | | | | In particular, give line numbers when detecting corrupt patches. This makes the tool a lot more friendly (indeed, much more so than regular "patch", I think).
* git-apply: bad patch fragments are fatalLinus Torvalds2005-05-23
| | | | | Don't just stop at them and look for the next header. Die, die, die!
* Start implementing "git-apply"Linus Torvalds2005-05-23
This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
generated by cgit v1.2.1 (git 2.18.0) at 2024-11-06 20:45:36 +0000