Re: GSoC draft proposal: Line-level history browser

Hi,

On Mon, 22 Mar 2010, Jakub Narebski wrote:

Bo Yang [off-list ref] writes:

quoted

This project will add a new feature for 'git log' to display line 
level history. It can trace the history of any line range of certain 
file at any revision. For simplity, users can run the command like: ' 
git log -L builtin/diff.c:6,8 ', he will get the change history of 
code between line 6 and line 8 of the diff.c file.

I think that, at least at first, line-level log should follow the
git-blame, i.e.

  git log -L <begin>,<end>  <revs>  -- <file>

If we want (in the future) to follow history of some lines from one
file, and other lines from other file together, we do not need to use

  -L <file>:<begin>,<end>

syntax.  If parseopt allows, we can use posotion of parameters, i.e.

  <file1> -L <m>,<n>   <file2> -L <k>,<j>

Oh, is it bikeshedding time already? /me might have missed the start 
signal.

quoted

And for each history entry, it will provide the commits, the diff 
block which contains changes of users' interested lines.

The most important *new* algorithm you need to implement is, after 
finding (blame-like) the commit that created given version of given 
line, what was previous version of given line and which line that was.

You can probably find some heuristic in existing merge tools, like
emerge from GNU Emacs, or graphical diff tools.

I do not think that these tools can help, as they never look further than 
identical lines (and they mustn't, either).

More importantly, the first step really is about driving the libxdiff in 
such a way that you can recognize the exact same lines.

(One point to note for the technical details: the algorithm has to expect 
opposite code moves, i.e. it must cope well when the diff shows the code 
in question removed in one hunk and added in another.)

We also should not get ahead of ourselves, but allow the student to get a 
full understanding of the requirements, from which he can then make a 
project plan (with milestones, Christian, no problem).

BTW by "requirements" I do not mean something as technical as the syntax, 
but rather a definition what people should be able to expect to do with 
this at the end of the summer.

As to fuzzy matching of lines that could not be attributed otherwise, I 
think that that will require a lot of playing around with different ideas. 
A simple Levenshtein-Damerau is highly unlikely to be enough.

Ciao,
Dscho