git-blame, take 2
authorFredrik Kuivinen <freku045@student.liu.se>
Thu, 2 Mar 2006 21:28:17 +0000 (22:28 +0100)
committerJunio C Hamano <junkio@cox.net>
Thu, 2 Mar 2006 23:10:39 +0000 (15:10 -0800)
commitfc675b8cd5ac102651c322e05d27c4fa7609f7a6
tree2e8587f09b0527c5d4bffe2009ea2180ef112b64
parentc40610422e1157e71dbc3c1a2f9e19bbe117962f
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>
blame.c