Re: git apply behaves differently from patch(1)

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