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>

0 files changed, 0 insertions, 0 deletions