From: Linus Torvalds Date: Tue, 20 Sep 2005 05:03:00 GMT Subject: Re: GIT - breaking backward compatibility Message-ID: 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