Re: blame --reverse selecting wrong commit

On Sun, May 29, 2011 at 19:21, Shawn Pearce [off-list ref] wrote:

Although blame shows Stefan Lay removed the block in commit 05fa1713,
this isn't what happened. It was actually removed in commit 2302a6d3
by Christian Halstrick. It looks like blame gets confused around this
section of the JGit history.

Repository URL:  git://egit.eclipse.jgit/jgit.git

$ git blame -L 1080, --reverse 40fa75feb..master --
org.eclipse.jgit.test/tst/org/eclipse/jgit/storage/file/RefDirectoryTest.java

Actually, you can use a narrower history range of 16e810b2..aa05559.

I found this glitch while working on the new JGit implementation of
reverse blame. It just so happens you and I both took the same rule on
a merge commit, follow the parent that has exactly the blob of the
merge itself... passing all blame onto it.

Except that in reverse mode this isn't true. One of the "parents" is
the descendent that deleted this method, so of course its not
identical content. The other parent is a different side-branch that
didn't touch the file at all. Later blame finds these branches merge
together, and lays the blame on the wrong side.

It seems that we may want to avoid "parents" that have identical file
content when in reverse mode if there is another parent that has
different content for the current target path.

-- 
Shawn.