* git blame --reverse doesn't find line in HEAD
@ 2017-11-29 8:06 Nick Snyder
2017-12-06 15:40 ` Nick Snyder
0 siblings, 1 reply; 5+ messages in thread
From: Nick Snyder @ 2017-11-29 8:06 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: git blame --reverse doesn't find line in HEAD
2017-11-29 8:06 git blame --reverse doesn't find line in HEAD Nick Snyder
@ 2017-12-06 15:40 ` Nick Snyder
2017-12-06 17:22 ` Junio C Hamano
0 siblings, 1 reply; 5+ messages in thread
From: Nick Snyder @ 2017-12-06 15:40 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: git blame --reverse doesn't find line in HEAD
2017-12-06 15:40 ` Nick Snyder
@ 2017-12-06 17:22 ` Junio C Hamano
2017-12-06 18:00 ` Nick Snyder
0 siblings, 1 reply; 5+ messages in thread
From: Junio C Hamano @ 2017-12-06 17:22 UTC (permalink / raw)
To: Nick Snyder; +Cc: git
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: git blame --reverse doesn't find line in HEAD
2017-12-06 17:22 ` Junio C Hamano
@ 2017-12-06 18:00 ` Nick Snyder
2017-12-07 17:02 ` Nick Snyder
0 siblings, 1 reply; 5+ messages in thread
From: Nick Snyder @ 2017-12-06 18:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
> 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.
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: git blame --reverse doesn't find line in HEAD
2017-12-06 18:00 ` Nick Snyder
@ 2017-12-07 17:02 ` Nick Snyder
0 siblings, 0 replies; 5+ messages in thread
From: Nick Snyder @ 2017-12-07 17:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
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.
>>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-12-07 17:03 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-29 8:06 git blame --reverse doesn't find line in HEAD Nick Snyder
2017-12-06 15:40 ` Nick Snyder
2017-12-06 17:22 ` Junio C Hamano
2017-12-06 18:00 ` Nick Snyder
2017-12-07 17:02 ` Nick Snyder
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).