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

- From: Davide Libenzi \<hidden\>
- Date: 2016-06-15 22:42:22 
- List: git
- Page: https://ratatoskr.run/git/2016/06/7280590
- Thread: https://ratatoskr.run/git/2016/06/7280552/t.md

```text
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
```