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.
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 perhaps this discussion would motivate somebody to finish that part
off, and tig and other Porcelains can just read the necessary line number
from the git-blame output.
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)
David Lang
--
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
