git blame --reverse doesn't find line in HEAD

> I have a repo that reproduces a behavior with `git blame --reverse`
> that surprises me. https://github.com/nicksnyder/git-blame-bug
>
> The readme explains the observed behavior and what I expected to
> happen. I will inline the readme at the bottom of this message for
> convenience.
>
> Am I misunderstanding --reverse or is this a bug?
>
> Thanks!
> Nick
>
> $ git --version
> git version 2.15.0
>
> Blame of L465 in Tree.tsx at HEAD (ca0fb5) points to L463 at 199ee7
>
> $ git blame -p -L465,465 Tree.tsx
> 199ee75d1240ae72cd965f62aceeb301ab64e1bd 463 465 1
> filename Tree.tsx
>             public shouldComponentUpdate(nextProps: TileProps): boolean {
>
> EXPECTED: Reverse blame of L463 at 199ee7 points to L465 at the
> lastest commit in the repo (at least ca0fb5).
> ACTUAL: Reverse blame of L463 at 199ee7 points to L463 at 199ee7.
>
> $ git blame -p -L463,463 --reverse 199ee7.. Tree.tsx
> 199ee75d1240ae72cd965f62aceeb301ab64e1bd 463 463 1
> boundary
> previous ca0fb5a2d61cb16909bcb06f49dd5448a26f32b1 Tree.tsx
> filename Tree.tsx
>             public shouldComponentUpdate(nextProps: TileProps): boolean {
>
> The line in question is in the diff (git diff 199ee7..ca0fb5), but
> that particular line is neither added nor deleted, so I don't know why
> blame would think it is deleted.
>
> Relevant hunk in diff:
>
> @@ -452,28 +462,17 @@ export class LayerTile extends
> React.Component<TileProps, {}> {
>          }
>      }
>
> -    public validTokenRange(props: TileProps): boolean {
> -        if (props.selectedPath === '') {
> -            return true
> -        }
> -        const token = props.selectedPath.split('/').pop()!
> -        return token >= this.first && token <= this.last
> -    }
> -
>      public shouldComponentUpdate(nextProps: TileProps): boolean {
> -        const lastValid = this.validTokenRange(this.props)
> -        const nextValid = this.validTokenRange(nextProps)
> -        if (!lastValid && !nextValid) {
> -            // short circuit
> -            return false
> +        if (isEqualOrAncestor(this.props.selectedDir,
> this.props.currSubpath)) {
> +            return true
>          }
> -        if (isEqualOrAncestor(this.props.selectedDir,
> this.props.currSubpath) && lastValid) {
> +        if (nextProps.selectedDir === nextProps.currSubpath) {
>              return true
>          }
> -        if (nextProps.selectedDir === nextProps.currSubpath &&
> this.validTokenRange(nextProps)) {
> +        if (getParentDir(nextProps.selectedDir) === nextProps.currSubpath) {
>              return true
>          }
> -        if (getParentDir(nextProps.selectedDir) ===
> nextProps.currSubpath && this.validTokenRange(nextProps)) {
> +        if (!isEqual(nextProps.pathSplits, this.props.pathSplits)) {
>              return true
>          }
>          return false

> Nick Snyder <nick@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.
>

>> 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 <gitster@pobox.com> wrote:
>> Nick Snyder <nick@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.
>>