> Can you bisect to see when the feature stopped working as you expect? I will see if I can do that but might take some time.
> It finds up to which commit each line survived without getting touched since > the oldest commit in the range. Right, this is where it is failing in my case. With a history like this: A <- B <- C <- HEAD I have a particular line in C (HEAD) that blames to commit A. If I run a git blame --reverse starting at commit A for that line, it doesn't give me back C, it gives me back B instead. The line is not added/deleted/moved between B and C. On Wed, Dec 6, 2017 at 9:22 AM, Junio C Hamano <gits...@pobox.com> wrote: > Nick Snyder <n...@sourcegraph.com> writes: > >> This can be reproduced on Linux and Mac. This behavior seems to be a bug. > > Can you bisect to see when the feature stopped working as you expect? > > Unlike a forward blame, where the command tries to find a commit > that is responsible for a line being in the final result (i.e. > typically, HEAD), a reverse blame is not about finding a commit > that is responsible for a line (that used to be in the oldest > commit) not being in a more recent codebase. It finds up to which > commit each line survived without getting touched since the oldest > commit in the range. >
