Re: GSoC draft proposal: Line-level history browser

Hi,

[please do not cull the Cc: list]

On Sat, 20 Mar 2010, Bo Yang wrote:

I (Johannes) wrote:

quoted

I think that that might be good for starters, but one could imagine 
that an integration into "git log" might be even better, so that gitk 
can use this without any further changes.

So, I think add some new options to 'git log' is preferred.

Yes, I think that this should be the target for the user interface. 
However, the logic should be different enough to merit a completely new 
file for the code (think "git add --interactive").

quoted

It would be good if the code looked harder after failing with the 
simple strategy, such as looking for code removed in other files, 
fuzzy matching (optional), and looking for code duplication (i.e. 
literal copying, or slightly modified copying).

The fuzzy matching might be necessary to catch things like a Java 
class moving from one file into another (and changing its name): the 
first line changes, but not completely.

That's really a good idea.
So, when the program reach the end of the history thread of some
changes of line range, it should not stop immediately. It then should
make a harder code search and try to find whether the new add lines of
code is moved to there or just copied from other place to there. And
these kind of search should use fuzzy matching instead of exact string
matching.

But notice that, detect code movement in one commit is much efficient
than detecting code copy. So, I think we should add an option to
control whether we detect such kind of code copy. By default, we
detect code move but not code copy. How do you think about this?

Yes, it is much more difficult, and it is more expensive. So: there are 
several steps in the project (you could also call them "milestones"), and 
fuzzy matching end lines would come later than simple code movement. And 
still later than code movement between files.

quoted

Just have a look at the word-level diff (--color-words):

http://repo.or.cz/w/git/dscho.git/blob/bc1ed6aafd9ee4937559535c66c8bddf1864bec6:/diff.c#l382

You will see that there is a function fn_out_diff_words_aux(), which 
is passed to xdi_diff_outf(). That latter function calls xdiff such 
that the former function receives a complete line at a time. And this 
is what I would suggest doing in the line-level log, too.

I have look over the function fn_out_diff_words_aux, this function parse 
each line of a memory diff. We can use it to detect the diff hunk head 
and find the line change. If you think the performance is acceptable, I 
think using this callback mechanism is all right.

Yes, I think that the performance is alright there, it works well enough 
for --color-words.

Thanks,
Dscho