Re: GIT - breaking backward compatibility

On Tue, 20 Sep 2005, Brian Gerst wrote:

That would be great, if git-apply accepted fuzzy patches.  I am trying 
to apply the -mm series patches, which often are slightly out of date. 
Andrew doesn't rebase them until they won't apply at all.

Patches welcome..

Actually, fuzzy patches themselves are pretty easy to do (yeah, the
"memcmp" needs to become something smarter - not a huge deal), but one big
issue is what the "priority" should be.

Should we prefer an exact match that is a hundred lines away from the line 
indicated, over a fuzzy patch that is right where we indicated? What if 
it's 50 lines and 10 lines? What if there's one that applies with fuzz 1 
that is further away from one that applies with fuzz 2? 

Personally I don't much like fuzzy patches. I think it's perfectly valid 
to say "try exact patch by default, and do that really fast", and then 
fall back on something slower for the fuzzy case.

In other words: I'd suggest you use git-apply --index by default. It fails
very gracefully: if will apply _all_ of a patch, or it won't apply
anything at all (that means that if the last of a hundred files will 
fail, git-apply will not have modified any of the first 99 either).

In other words, git-apply has _none_ of that traditional "patch" crap
behaviour. It does patch application _right_.

Of course it does. I wrote it.

		Linus