Shawn Pearce <spearce@xxxxxxxxxxx> writes: >> 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html