Re: blame --reverse selecting wrong commit

From: Shawn Pearce <spearce@spearce.org>
Date: May 30, 2011, 02:33 UTC
Message-ID: <BANLkTimAij28ibW3DV2HaHPK5z0D-CrDHQ@mail.gmail.com>
In-Reply-To: <BANLkTikuFEg686VH_RojEe-zmBZRBOx6eA@mail.gmail.com>

On Sun, May 29, 2011 at 19:21, Shawn Pearce <spearce@spearce.org> wrote:

Show 9 quoted lines

> 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.