Re: Use a *real* built-in diff generator
- From
- Davide Libenzi <davidel@xmailserver.org>
- Date
- Mar 25, 2006, 18:14 UTC
- Message-ID
- <Pine.LNX.4.64.0603251009500.11968@alien.or.mcafeemobile.com>
- In-Reply-To
- <Pine.LNX.4.64.0603250742340.15714@g5.osdl.org>
On Sat, 25 Mar 2006, Linus Torvalds wrote:
Show 24 quoted lines
> On Sat, 25 Mar 2006, Linus Torvalds wrote: >> >> I'll be taking a look at trying to fix it. > > Actually, it ended up being easier than I expected it to be. > > This (on top of the previous patch) should fix it. > > And yes, with this, I can pass the output of > > git diff v2.6.16.. > > to "git-apply" and it not only passes the "--stat" thing (which verifies > that git-apply is happy with the diff) but it also results in exactly the > same tree when applied on top of v2.6.16 (and the patch has two cases > where the "no newline" test triggers). > > The speed-up is quite noticeable, especially when doing things like > > git diff v2.6.16.. | git-apply --stat > > which just _used_ to be painfully slow (25 seconds for me) and is now > under five seconds. That's the difference between "twiddling your thumbs" > and "ok, that wasn't too bad".
Yeah, that works. It has never been an algorithm problem, but a diff output one. And following what GNU diff does looks fine to me. I'll fix libxdiff with that. I also have to teach libxdiff patch algo to recognize the tag and do the right thing during the patch operation.
> 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.
- Davide