Re: Use a *real* built-in diff generator
- From
Petr Baudis <pasky@suse.cz>
- Date
- Mar 26, 2006, 18:20 UTC
- Message-ID
- <20060326182028.GP18185@pasky.or.cz>
- In-Reply-To
- <20060326110934.GA3774@linux-mips.org>
Dear diary, on Sun, Mar 26, 2006 at 01:09:35PM CEST, I got a letter where Ralf Baechle <ralf@linux-mips.org> said that...
Show 14 quoted lines
> On Sat, Mar 25, 2006 at 10:39:03AM -0800, Linus Torvalds wrote: > > > Besides, I hate how GNU patch bends over backwards in applying crap that > > isn't a proper patch at all (whitespace-corruption, you name it: GNU patch > > will accept it). Also, I made "git-apply" be all-or-nothing: either it > > applies the _whole_ patch (across many different files) or it applies none > > of it. With GNU patch, if you get an error on the fifth file, the four > > first files have been modified already - aarrgghhh.. > > Which is apply's greatest strength - and weakness. GNU diff doesn't > understand the file renamings bits of git diffs, so they they need to be > used with apply. So if a patch doesn't apply? Apply doesn't even have > an option to apply things as good as it can and leave the rest in > reject files. Yuck.
I've just updated cg-patch on the master branch today to understand file renames, so it should be possible to use it for applying fuzzy patches. (OTOH, cg-patch has grown way too complex and ugly for my taste. It'd be nice if git-apply could take over the ugly part of the task.)
No dice with patches containing copy information, though. We would need to perform the copy _before_ applying the patch itself and we have no infrastructure for that (so far it has been enough to do the git-specific stuff after applying the patch itself).
-- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Right now I am having amnesia and deja-vu at the same time. I think I have forgotten this before.