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

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

[Nick Snyder]

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

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

[Nick Snyder]

This can be reproduced on Linux and Mac. This behavior seems to be a bug.

On Wed, Nov 29, 2017 at 12:06 AM, Nick Snyder <nick@sourcegraph.com> wrote:
> 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

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

[Junio C Hamano]

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.

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

[Nick Snyder]

> 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.
>

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

[Nick Snyder]

I built from source and was unable to find a git version where this
has ever worked correctly.

I wasn't able to compile and test versions older than 1.6.1.

Confirmed not working:
2.15.1
2.13.6 (Apple Git-96)
2.0.0
1.7.0
1.6.3
1.6.2
1.6.1

I updated the https://github.com/nicksnyder/git-blame-bug with a
script to easily reproduce.

On Wed, Dec 6, 2017 at 10:00 AM, Nick Snyder <nick@sourcegraph.com> wrote:
>> 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.
>>