git-blame, take 2
Here is an updated version of git-blame. The main changes compared to
the first version are:
* Use the new revision.h interface to do the revision walking
* Do the right thing in a lot of more cases than before. In particular
parallel development tracks are hopefully handled sanely.
* Lots of clean-up
It still won't follow file renames though.
There are still some differences in the output between git-blame and
git-annotate. For example, in 'Makefile' git-blame assigns lines
354-358 to
455a7f3275d264f6e66045b92c83747ec461dda5 and git-annotate
assigns the same lines to
79a9d8ea0d88a3667ad19be8e705405ab5d896f1.
I think git-blame is correct in this case. This patterns occur in
several other places, git-annotate seems to sometimes assign lines to
merge commits when the lines actually changed in some other commit
which precedes the merge.
[jc: I have conned Ryan into doing test cases, so that it would
help development and fixes on both implementations. Let the
battle begin! ;-) ]
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>