Hi, On Mon, 22 Mar 2010, Jakub Narebski wrote: > Bo Yang <struggleyb.nku@xxxxxxxxx> writes: > > > 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. > > 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 -- 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