Thread (1 message) 1 message, 1 author, 2016-06-15

Re: blame --reverse selecting wrong commit

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:51:21

Shawn Pearce [off-list ref] writes:
quoted
Yeah.

It has always been my opinion that asking for "one commit past the blamed
one" is a undefined request (after all, blame for the line fell on that
commit exactly why the next commit does _not_ have any corresponding
line), so that is why I punted there.
I don't think its undefined. Normally with blame/annotate we want to
discover who put this line here, that is who did the insertion or
replacement that made this line show up in the result file.
Very true. The question that does not have a defined answer is "what
content was before this commit on that blamed line", and that is very
different from "what commit was there before this commit the line is
blamed for". The topic of this thread is the latter, and I was referring
the former which is offtopic because I was confused and tired.
The catch is, its slightly more expensive than forward because we pass
blame down *all* paths of a fork, rather than only the one that was
identical.
Hmm, I don't know. Isn't it just the matter of running the current
"reverse blame" to find the newest revision that had the line (without any
"dig wider"), and then dig a single level wider by comparing that revision
and all its children to see which child has the line in question removed?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help