git apply behaves differently from patch(1)

In the following usecase git apply (git version 1.5.4.rc3.15.g785f9) doesn't do what I expect it should do. I expect it to do the same as patch does in the same situation.

To reproduce; Create a file 'test' with a number on each line. Numbers 1 though 10. $ for i in 1 2 3 4 5 6 7 8 9 10; do echo $i >> test; done $ git add test $ git commit test

$ rm test $ for i in 1 3 4 5 6 7 10; do echo $i >> test; done $ git diff-index -p --unified=0 HEAD test | tee mypatch

Now use your editor to edit 'mypatch' and remove the first hunk; the end result (after your editing) should be something like this; $ cat mypatch

Thomas Zander schrieb:

[... hand-edit a patch without context ...]

It's not exactly a bug. The behavior of zero-context patches is simply not well-defined. You have just been lucky that patch worked in the way that you expected. Don't use zero-context patches.

That said git-apply can certainly be modified to behave like patch in this case. I tried, but gave up - it's too much code that is new to me. :(

-- Hannes

On Wed, 16 Jan 2008, Thomas Zander wrote:

There's actually a lot of cases where git-apply doesn't really do what patch does.

There's one really obvious difference, in that git-apply only does unified diffs and doesn't support any of the traditional ones: that may be seen as a downside, but I was never interested in them, so it's a "limitation" only in the sense that git-apply just doesn't do the ass-backwards old formats.

But this definitely means that "git-apply" doesn't really _replace_ patch per se.

There's also the very explicit differences, ie git-apply has all the extensions for renaming etc.

But in addition to those limitations and extensions there are the much subtler ones, which tend to come down to different interpretations of what is "safe".

What you hit is one such difference. There are others. They all boil down to "I'm not sure enough I can apply this correctly, so I won't":

 - (the one you hit): zero context at the end means "end-of-file"

   There's no other valid reason to have zero context in git-apply's 
   opinion, because without the context, there's no way to verify that 
   we're applying things in the right place.

 - git doesn't guess how deep the path is by default.

 - git does not accept any fuzz by default

In other words, git-apply simply doesn't want to apply unsafe patches. Yes, they often (probably 99% of the time) would apply in the right place, but partly *because* they often work, people are so used to doing them that then the few cases where they silently apply incorrectly are even more painful and often aren't noticed.

So no, git-apply really isn't a straight replacement for GNU patch. 

You can't really get exactly the same behaviour with any flags (there is no "guess filename path depth" mode at all, for example), but you can get fairly close with

	git-apply -C1 --unidiff-zero

where that -C1 matches GNU patches (INSANE!) default fuzz of 2, and the --unidiff-zero thing disables the stricter git-apply rules for no context.

I would actually suggest you go the other way: rather than try to make git-apply mimic the unsafe defaults of GNU patch, try to teach yourself to use the stricter rules. It's not always practical, but generally, the things git-apply refuses to do by default really *are* rather likely to mis-apply a patch occasionally.

(Even with git-apply's strict defaults, there is obviously no *guarantee* that a patch will always apply correctly, but at least git-apply will strictly check as much of the information that is available in the patch)

			Linus