On Sat, 25 Mar 2006, Davide Libenzi wrote: > > > 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 - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html