Hi, [please do not cull the Cc: list] On Sat, 20 Mar 2010, Bo Yang wrote: > I (Johannes) wrote: > > > 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"). > > 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. > > 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 -- 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