Hi Johannes,
Thank you very much for your advice!
>
> I like it very much already! You obviously put in a substantial amount of
> time to learn intricate details about the way Git operates, and what is
> already available.
>
> And you also provided a patch (unrelated to line-level history browser),
> so you proved that you actually cloned Git, and that you can actually
> patch it and use Git itself to send a patch to this list.
I am very happy you like it.
>
> 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.
>
> 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?
> 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.
Regards!
Bo
--
My blog: http://blog.morebits.org
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html