Re: [PATCH v3 05/13] parse the -L options

Thomas Rast <trast@student.ethz.ch> writes:

I think "log -L" conceptually is very different from the normal "log with pathspecs".

The "log with pathspecs" is about "I have these histories that lead to these commits; show commits that touch paths that match them". On the other hand, "log -L" asks "I have these lines in these files; explain how they came about in the history leading to...". Now, the question is: "leading to" WHAT?

Because you start from "I have _these lines_", you are fundamentally discussing contents that appear as a set of line ranges _in a particular version_, adjusting the range to match their older incarnations as necessary as you dig deeper, no?

I would say that this is not just _only_ the implementation and option parsing. What is happening looks to me fundamentally very different.

Having said that, it is not entirely implausible to imagine that "log -L" can further be enhanced to also dig into the future. The request becomes "I have these lines; explain how they came about, and how they went".

E.g. if you have a history of this shape where commit C is at the tip:

    ---o---A---x---B---o---C

you _could_ ask "log -p -L1,10,B:Makefile A..C" (I am not proposing this syntax at all, by the way) to browse the history between A and C, looking for commits that touch the region of Makefile that appeared as lines 1..10 in revision B. Between B and C, some new lines might have been introduced inside the range and you would dig in reverse enlarging the range to show what have been added to it.

If you have that kind of "forward digging", then it would also not be implausible to deal with a forked history like this:

                 y---z---D
                /
    ---o---A---x---B---o---C

and ask a similar "log -p -L1,10,C:Makefile A..C D" question. You would need to dig from C to x, finding the corresponding range in x, and then map that corresponding range further while traversing through y, z and to D in reverse, just like you mapped and traversed from B through o to C in reverse that explained a part of Makefile in revision B in the earlier example.

Also the implementation will have to be very different if you really wanted to do this properly. I would imagine you would first build a sparse merge-simplified graph that consists of commits that touch Makefile (using "Makefile" as a pathspec) in the first pass, map the line ranges backward and forward in the second pass, and output the result in the final pass. Presumably you could collapse the backward traversing half of the second pass and the third one (which is what Bo's patchset already does), but I don't think you can stream x-y-z-D going forward, as "log -L" output needs to follow the usual new-to-old order as the other parts of the history.

IOW, that "explain how they came and how they went" is also very different from the normal "log", even if you choose to lift that restriction.

Also I am not entirely sure if it is easy to explain to the users.

If you instead choose to retain the "start from one commit", then the way you ask the question becomes "I have these lines in these files at this commit; explain how they came about in the history", which is exactly what you ask "blame". You are just using a different presentation from what the default "blame" output gives.

I would consider it similar to "blame --incremental"; you can choose a very different output format driven by a single switch to change the mode of operation.