Re: Use a *real* built-in diff generator

On Sat, 25 Mar 2006, Davide Libenzi wrote:

quoted

Now, to be honest, the real reason I wanted a built-in diff wasn't the
speed advantage, but the fact that it's so much more flexible. The lack of
fork/exec just allows us to do things that weren't practical before.

I don't know if git is patch-forkexec sensitive or not, but if it is you can
take a look at libxdiff's xdl_patch(), or at libifying GNU patch.

I don't need "patch", since I wrote my own anyway. It's just called 
"apply" instead of "patch".

Doing "apply" is not only much simpler than doing "diff", but I needed my 
own much earlier: it's much more timing-critical for me (applying 200 
patches in one go), and git needed something that could honor renames and 
copies, and the mode bits too.

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..

See "apply.c" for details if you care. It's stupid, but it works (and it 
_only_ handles unified diffs - with the git extensions, of course).

(I also absolutely hate the GNU coding standards, so I'd be very unlikely 
to libify any of the FSF projects. With libxdiff, I can actually read the 
code: it may be a bit dense at times, but at least the code is written to 
be readable, unlike most FSF projects).

			Linus