On Sat, 25 Mar 2006, Linus Torvalds wrote:
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
-
: 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