Re: GIT - breaking backward compatibility

From: Linus Torvalds <torvalds@osdl.org>
Date: Sep 20, 2005, 05:03 UTC
Message-ID: <Pine.LNX.4.58.0509192156310.2553@g5.osdl.org>
In-Reply-To: <432F92FC.4000405@didntduck.org>

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