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
283a60d1 (Shawn O. Pearce 2011-05-26 17:25:59 -0700 1080) }
05fa1713 (Stefan Lay 2011-05-24 01:38:59 -0700 1081)
05fa1713 (Stefan Lay 2011-05-24 01:38:59 -0700 1082) /**
05fa1713 (Stefan Lay 2011-05-24 01:38:59 -0700 1083) *
Kick the timestamp of a local file.
05fa1713 (Stefan Lay 2011-05-24 01:38:59 -0700 1084) * <p>
05fa1713 (Stefan Lay 2011-05-24 01:38:59 -0700 1085) * We
shouldn't have to make these method calls. The cache is using file
05fa1713 (Stefan Lay 2011-05-24 01:38:59 -0700 1086) *
system timestamps, and on many systems unit tests run faster than the
05fa1713 (Stefan Lay 2011-05-24 01:38:59 -0700 1087) *
modification clock. Dumping the cache after we make an edit behind
05fa1713 (Stefan Lay 2011-05-24 01:38:59 -0700 1088) *
RefDirectory's back allows the tests to pass.
05fa1713 (Stefan Lay 2011-05-24 01:38:59 -0700 1089) *
05fa1713 (Stefan Lay 2011-05-24 01:38:59 -0700 1090) * @param name
05fa1713 (Stefan Lay 2011-05-24 01:38:59 -0700 1091) *
the file in the repository to force a time change on.
05fa1713 (Stefan Lay 2011-05-24 01:38:59 -0700 1092) */
05fa1713 (Stefan Lay 2011-05-24 01:38:59 -0700 1093)
private void BUG_WorkAroundRacyGitIssues(String name) {
--
Shawn.
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.
On Sun, May 29, 2011 at 19:33, Shawn Pearce [off-list ref] wrote:
On Sun, May 29, 2011 at 19:21, Shawn Pearce [off-list ref] wrote:
quoted
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.
Oh. Re-reading the man page for git blame helps. It says blame shows
the last revision that a line exists in, rather than the revision that
removed the line. IMHO, I expected reverse to show me the revision
that deleted (or replaced) that line, so I can inspect the commit
message and the contents of the patch. Showing me one of the potential
parents of that revision seems to be nearly useless.
Rereading commit 85af7929ee ("git-blame --reverse"), it seems you left
this an "exercise for the reader"... and in the past 3 years, no
reader has stepped forward to implement the exercise as a patch to
blame. *sigh*
--
Shawn.