Some observations on log -L

Some observations on log -L

[Ramkumar Ramachandra]

Hi,

Ever since 'git log -L' made it to `pu`, I've been playing with it to
see how it can be useful.  Here are some of my observations:

1. Specifying line ranges by hand are too painful.  I would really
love it if it could parse the lines off a patch prepared by
format-patch or something.

2. Specifying regex ranges are really useful to see the history of a
function.  But I think it could really benefit from a tool that
actually understands the language (using Clang Tooling).  If we were
to build such a tool, git-core could benefit immensely from it: we'd
have smarter merges too, for instance.

3. Often, I want to know the people to contact for a segment of code.
Blame is useless here, because it only considers the most recent
commit, when I want to know the authors of all the commits that helped
shaped that segment of code.  So, I think shortlog could really
benefit from a -L.  Is this easily doable?

Thanks for listening.

Re: Some observations on log -L

[Thomas Rast]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Ever since 'git log -L' made it to `pu`, I've been playing with it to
> see how it can be useful.  Here are some of my observations:
>
> 1. Specifying line ranges by hand are too painful.  I would really
> love it if it could parse the lines off a patch prepared by
> format-patch or something.

True, but I'm not sure that starting from a patch is the right thing.
At least in my case, when I have a patch ready, I longer need to
investigate anything ;-)

Perhaps a "line-log all the ranges touched by this commit" would be more
useful.

You can achieve both with some hack like

  eval git log 1640632 $(git show 1640632 | perl -ne '
    $h=1 if /^diff /;
    $f=$1 if $h and m{\+\+\+ ./(.*)$};
    if (/@@ .* \+(\d+)(?:,(\d+))/) {
      print " -L$1,+$2:$f"; $h=0;
    };
  ')

Note that you need to specify the commit in two places.  I think I'll
actually make that a script and try it to see if it's worth
implementing.  Quoting of the -L args is of course an exercise left to
the reader ;-)

> 2. Specifying regex ranges are really useful to see the history of a
> function.  But I think it could really benefit from a tool that
> actually understands the language (using Clang Tooling).  If we were
> to build such a tool, git-core could benefit immensely from it: we'd
> have smarter merges too, for instance.

Is there any research on this?

I imagine you would use whatever parser you have at hand to process the
input into a syntax tree, then run diff over those trees.  There should
be some research on how to get meaningful diffs of them?  And then you
somehow have to turn the tree-diff into a human-readable output.

In any case you could start by prototyping such a diff algorithm on a
file basis; people could then start using it as an external diff driver.

> 3. Often, I want to know the people to contact for a segment of code.
> Blame is useless here, because it only considers the most recent
> commit, when I want to know the authors of all the commits that helped
> shaped that segment of code.  So, I think shortlog could really
> benefit from a -L.  Is this easily doable?

Not really.  You're touching on a sore point of the current
implementation, which is that it's not properly tied into the log and
diff infrastructures.  I figured that would block it for too long, so I
gave up on trying to do that for the first version.

So it just runs captures the history that log walks, does a separate
processing step and handcrafts a diff in its own output machinery, which
isn't very nice for many reasons, including that we can't run any other
diff- or log-like stuff on top of log -L output.

That precludes many uses, like shortlog you mentioned, or color-words.
I think Junio and me hashed out some ideas for how it *should* be tied
together in some earlier thread.  The gist of it is that there are
really three separate things going on here:

* Pathspec-like filtering with proper -M support.  This should be
  unified with --follow.  That's actually the next thing I want to try,
  because it should give a properly implemented --follow along the way.

* A pass of commit filtering based on intersecting the ranges we're
  interested in with the diffs of commits, and mapping them "across".
  This should be hooked as a cleanly separated step into the log
  machinery.

* Diff output filtering based on the ranges that we found.  This should
  be done as a filter somewhere in the diff machinery, preferably before
  word-diff.

(The first step is actually a performance optimization, but it would not
be a practical algorithm without it.)

Thanks for the input.  Let me know if you manage to break it somehow :-)


And for a bit of shameless pluggery (you probably saw it on IRC already,
but mainly for other curious readers):

  git://github.com/trast/git.git tr/gitk-line-log

has a version of gitk that supports -L.  I hacked it up yesterday, and
while it seems to work, I want to play with it a little until I'm
satisfied that I didn't break gitk for other uses.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch