On Sat, Feb 7, 2009 at 09:55, <david@xxxxxxx> wrote: > On Fri, 6 Feb 2009, Junio C Hamano wrote: >> Jeff King <peff@xxxxxxxx> writes: >>> My impression is that tig is currently doing (1). I think (2) will >>> suffer from the same problem, but in practice the margin of error will >>> be much smaller because your are rewinding through fewer changes. So if >>> that is what you were suggesting, I think it is probably worth trying. Tig wasn't using the line number or even the filename, this has now been fixed. >> It has been quite a while since I did the "show previous" feature of >> "git-blame --porcelain" that has been forever queued in 'next'; if I >> remember correctly, it implemented (2). >> >> The reason why it never graduated from 'next' is exactly this issue. By >> definition, there is no "previous" line number (if there were such a thing >> that says "This line was at line N in the parent of the blamed commit", >> then the commit wouldn't have taken the blame but would have passed it >> down to the parent), and we need to come up with a reasonable heuristics. So it ist somewhat safe to assume that the line didn't originate from a different file, since git-blame would have picked that up? > this sounds like the same basic problem I was having around the begninning > of the year (thread subject 'how to track the history of a line in a file') > what I ended up doing was to use git blame to go back and find the commit > where a line was introduced, then use git diff to find the changes, then > find the hunk of the diff that introduced the line, then find the lines that > were removed and trace them back (repeating the process) I've tried to implement something like this by using the output of "git-diff-tree -U0". One problem it does not yet handle is the cut'n'paste within the same file where the deleted line ends up in a different hunk. So it won't jump to the correct place if you try to trace back for example the origin of the parse_options function in tig.c since at some point I moved it down in the file. However, it does work quite well for tracing back the origin of for example the DATE_COLS macro which was rewritten a few times. I guess it comes down to what you can assume about the features or "uniqueness" of the line (or lines) that are being traced back and whether the history and commits are well organized. -- Jonas Fonseca -- 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
