Wrap up of Line Level History Browser

Wrap up of Line Level History Browser

[Bo Yang]

Hi,

Today is the last day of GSoC, here is a wrap up of the whole work of
this summer from Line Level History Browser.

Generally, the goal of this project is to:
1. 'git log -L' to trace multiple ranges from multiple files;
2. move/copy detect when we reach the end of some lines(where lines
are added from scratch).

And now, we have supports in detail:
1. 'git log -L' can trace multiple ranges from multiple files;
2. we support the same syntax with 'git blame' '-L' options;
3. we integrate the 'git log -L' with '--graph' options with
parent-rewriting to make the history looks better and clear;
4. move/copy detect is in its half way. We get a nearly workable
version of it, and now it is in a phrase of refactor, so in the scope
of GSoC, move/copy detect only partly complete.

Now, the first series of patches of core 'git log -L' functionality is
cooked in 'pu' and the move/code detect code is in a refactor. That's
the general status of my project.

In the following days, some more work will be put into the refactor
and I hope I can make the re-written version appear in next week. :)

Finally, many thanks to my mentor Thomas, he helped me on designing
how to implement things and was very patient to point out the flaw of
various version of 'git log -L' and this make me improve my code
continuously. And thanks to Jens, Junio to provide so many valuable
comments. Thanks a lot!

-- 
Regards!
Bo
----------------------------
My blog: http://blog.morebits.org
Why Git: http://www.whygitisbetterthanx.com/

Re: Wrap up of Line Level History Browser [long]

[Thomas Rast]

Hi Bo, *

As a brief introduction to people who haven't been following, and
partially answering an earlier question in another thread:

David Lang wrote:
> what is this series?
> 
> this is all good incramental information, but there's no info indicating 
> what this is updating.

For me it replaces a manual iterative process to find out in what ways
a function was patched until it came to have its current shape:

  git-blame the area, find the most recent commit C
  while 1:
    git show C
    if that explains the code: break
    git-blame the area in C^
    find the most recent commit and call it C again

I do this a lot when a particular section of code puzzles me or seems
buggy, to see if any commit message provides a reason for it.  I think
(but I never got good with it) the "blame parent" feature of 'git gui
blame' covers a similar use-case.

All of this can now be replaced by a simple

  git log -L <range> <filename>

A good example that I did a lot of testing with:

  git log --graph be58e70d^ -L /builtin_funcname_pattern/,/^}/ diff.c

Try it.  I can follow up with more examples if you're interested, but
it's much more fun if you're actually looking for some explanations.


As for the project: First off, many thanks Bo for all the work you put
into it.  I think you planned and executed this project very well.
There were some minor changes to the original drafts, but comparing
the feature list from the project proposal (this is only an abstract,
the real list was much longer):

} 1. Line-history (main work :-)
} 2. -M/-C support
} 3. Configurable context
} 4. -C -C support
} 5. Fuzzy matching for -M/-C
} 6. Configurable display (--graph)
} 7. Machine-readable output (--porcelain)
} 8. Support git-log options where possible

with the feature list you posted

Bo Yang wrote:
> And now, we have supports in detail:
> 1. 'git log -L' can trace multiple ranges from multiple files;
> 2. we support the same syntax with 'git blame' '-L' options;
> 3. we integrate the 'git log -L' with '--graph' options with
> parent-rewriting to make the history looks better and clear;
> 4. move/copy detect is in its half way. We get a nearly workable
> version of it, and now it is in a phrase of refactor, so in the scope
> of GSoC, move/copy detect only partly complete.

we see that while there's still some work to be done in the -C -C
area, most of the features are there.  The ones that didn't make it
are 5 (fuzzy matching) and to some extent 3 (context control; there is
--full-line-diff).  We agreed to drop 7 (--porcelain) in private
conversation when we found out that gitk is already halfway ready to
read --format=full output.  Combined-diff style output for merges was
also added to the list sometime in summer, then dropped again because
of time constraints.


Next, thanks also to Jens who co-mentored.  Things went very smooth
despite my roughly 4 weeks of absence during the GSoC months thanks to
his efforts.


Finally, I'd like to outline some of my dreams^Wfuture directions for
this feature.  Some of them have been promised by Bo privately, but
let's not put any pressure on him now that the project is officially
over.

* Support in gitk to read --format=full output (within some
  constraints maybe), thus letting us see the output more
  conveniently.

* Support in gitk to parse the -L option and pass it to the right
  git-log invocation.

* Combined-diff style output for merges.

* As Junio has suggested in a thread about the option parsing, it
  should be possible to extend this to scan history both ways, i.e.,
  "I have lines 11-19 in commit abcdef, explain how they came and
  where they went".


I think that's all for today, thanks for reading so much text.

Regards

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

Re: Wrap up of Line Level History Browser [long]

[Jonathan Nieder]

Thomas Rast wrote:

> For me it replaces a manual iterative process to find out in what ways
> a function was patched until it came to have its current shape:
>
>  git-blame the area, find the most recent commit C
>  while 1:
>    git show C
>    if that explains the code: break
>    git-blame the area in C^
>    find the most recent commit and call it C again
[...]
> All of this can now be replaced by a simple
>
>  git log -L <range> <filename>
>
> A good example that I did a lot of testing with:
>
>  git log --graph be58e70d^ -L /builtin_funcname_pattern/,/^}/ diff.c

Thanks. (And thanks to Bo for implementing it!)