Re: [RFC/PATCH] add diff-pairs tool

[Jeff King]

On Thu, Dec 01, 2016 at 02:22:47PM -0800, Junio C Hamano wrote:

> Jeff King  writes:
> 
> >> It took me a while to dig it up because the topic is so old, but
> >> 
> >> https://public-inbox.org/git/pine.lnx.4.58.0504251832480.18...@ppc970.osdl.org/
> >> 
> >> is the thread I had in mind.  The idea of rename detection followed
> >> soon afterwards.
> >
> > Thanks for an interesting read. Your diff-tree-helper patch is very
> > similar to what I wrote.
> >
> > I do think the right decision was made back then. The single-process
> > model is much more efficient, and it was over 10 years until somebody
> > actually wanted to expose the functionality to a script (and even now,
> > I'm not convinced enough people want it to even merit inclusion).
> 
> Well, 10 years ago the person in the thread who argued "who cares
> about producing patches?  each step in plumbing should do one thing
> and one thing only and do so well" was Linus, so your coming up with
> the diff-tree-helper again may indicate that we may want to step
> back and retry the experiment again, perhaps?

I think there are two questions, looking historically.

One is whether the functionality should be exposed to scripts at all.

The second is, assuming it should be exposed, in which order to do it.
You can write a series of small scripts, and then tie them together. Or
you can write tie it all together in C, and then make specific helpers
to expose the various bits.

The advantage of the first technique is that the tools are used
consistently by all parts of the system, so you know they don't grow
weird bugs or fail to handle corner cases. The advantage of the second
is that most people want the "tied-together" functionality, and it can
run a lot faster in-process.

So mostly I was suggesting that the right decision 10 years ago was to
optimize for speed in the common case, and let people worry later about
whether they wanted to expose the functionality in more flexible ways.
And that brings us to today.

It sounds like you are in favor of adding diff-pairs (and certainly it
shouldn't _hurt_ anybody if they are not interested in using it; you'll
notice the patch didn't need to touch the diff code at all).

-Peff

Re: [RFC/PATCH] add diff-pairs tool

[Junio C Hamano]

Jeff King  writes:

>> It took me a while to dig it up because the topic is so old, but
>> 
>> https://public-inbox.org/git/pine.lnx.4.58.0504251832480.18...@ppc970.osdl.org/
>> 
>> is the thread I had in mind.  The idea of rename detection followed
>> soon afterwards.
>
> Thanks for an interesting read. Your diff-tree-helper patch is very
> similar to what I wrote.
>
> I do think the right decision was made back then. The single-process
> model is much more efficient, and it was over 10 years until somebody
> actually wanted to expose the functionality to a script (and even now,
> I'm not convinced enough people want it to even merit inclusion).

Well, 10 years ago the person in the thread who argued "who cares
about producing patches?  each step in plumbing should do one thing
and one thing only and do so well" was Linus, so your coming up with
the diff-tree-helper again may indicate that we may want to step
back and retry the experiment again, perhaps?

Re: [RFC/PATCH] add diff-pairs tool

[Jeff King]

On Thu, Dec 01, 2016 at 12:58:21PM -0800, Junio C Hamano wrote:

> Jeff King  writes:
> 
> > On Thu, Dec 01, 2016 at 12:52:05PM -0800, Junio C Hamano wrote:
> >
> >> Jeff King  writes:
> >> 
> >> > This takes the output of `diff-tree -z --raw` and feeds it
> >> > back to the later stages of the diff machinery to produce
> >> > diffs in other formats.
> >> 
> >> A full circle.  This reminds me of the experiment done more than 10
> >> years ago at the beginning of the "diffcore transformations" design.
> >
> > Heh, I didn't even think to dig for prior art on the list.
> 
> It took me a while to dig it up because the topic is so old, but
> 
> https://public-inbox.org/git/pine.lnx.4.58.0504251832480.18...@ppc970.osdl.org/
> 
> is the thread I had in mind.  The idea of rename detection followed
> soon afterwards.

Thanks for an interesting read. Your diff-tree-helper patch is very
similar to what I wrote.

I do think the right decision was made back then. The single-process
model is much more efficient, and it was over 10 years until somebody
actually wanted to expose the functionality to a script (and even now,
I'm not convinced enough people want it to even merit inclusion).

-Peff

Re: [RFC/PATCH] add diff-pairs tool

[Junio C Hamano]

Junio C Hamano  writes:

> It took me a while to dig it up because the topic is so old, but
>
> https://public-inbox.org/git/pine.lnx.4.58.0504251832480.18...@ppc970.osdl.org/
>
> is the thread I had in mind.  The idea of rename detection followed
> soon afterwards.

... which was this one:

https://public-inbox.org/git/7vr7g4m0lz.fsf...@assigned-by-dhcp.cox.net/#t

Re: [RFC/PATCH] add diff-pairs tool

[Junio C Hamano]

Jeff King  writes:

> On Thu, Dec 01, 2016 at 12:52:05PM -0800, Junio C Hamano wrote:
>
>> Jeff King  writes:
>> 
>> > This takes the output of `diff-tree -z --raw` and feeds it
>> > back to the later stages of the diff machinery to produce
>> > diffs in other formats.
>> 
>> A full circle.  This reminds me of the experiment done more than 10
>> years ago at the beginning of the "diffcore transformations" design.
>
> Heh, I didn't even think to dig for prior art on the list.

It took me a while to dig it up because the topic is so old, but

https://public-inbox.org/git/pine.lnx.4.58.0504251832480.18...@ppc970.osdl.org/

is the thread I had in mind.  The idea of rename detection followed
soon afterwards.

Re: [RFC/PATCH] add diff-pairs tool

[Junio C Hamano]

Jeff King  writes:

> This takes the output of `diff-tree -z --raw` and feeds it
> back to the later stages of the diff machinery to produce
> diffs in other formats.

A full circle.  This reminds me of the experiment done more than 10
years ago at the beginning of the "diffcore transformations" design.

Re: [RFC/PATCH] add diff-pairs tool

[Jeff King]

On Thu, Dec 01, 2016 at 12:52:05PM -0800, Junio C Hamano wrote:

> Jeff King  writes:
> 
> > This takes the output of `diff-tree -z --raw` and feeds it
> > back to the later stages of the diff machinery to produce
> > diffs in other formats.
> 
> A full circle.  This reminds me of the experiment done more than 10
> years ago at the beginning of the "diffcore transformations" design.

Heh, I didn't even think to dig for prior art on the list.

In a sense this is just bringing the full power of diffcore out to the
scripting interface. The one missing component is that you can't
actually call diffcore_std() in the middle. The full pipeline would I
guess be something more like:

  git diff-tree --raw -z $a $b |
  git detect-renames |
  git diff-pairs -p

or something. In my model it's sufficient for the rename detection to
happen as part of the first diff-tree (since it's a whole-tree operation
anyway, there's no benefit to breaking it up into chunks).

-Peff