Re: git bisect result off by 1 commit

Tim Chen [off-list ref] writes:

When I am doing a git bisect to track down a problem commit on the Linux 
kernel tree, I found that git bisect actually led me to a patch that's one
before the problem commit.

In particular,

$ git bisect replay bisectlog 
Previous HEAD position was d54b1a9... perf script: Remove use of die/exit
HEAD is now at a0d271c... Linux 3.6
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[d54b1a9e0eaca92cde678d19bd82b9594ed00450] perf script: Remove use of die/exit

However, the patch that is problematic is the one before the one git bisect indicated.
[commit 8d3eca20b9f31cf10088e283d704f6a71b9a4ee2].

Looks perfectly normal to me.  The message above:

HEAD is now at a0d271c... Linux 3.6
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[d54b1a9e0eaca92cde678d19bd82b9594ed00450] perf script: Remove use of die/exit

is asking you to test the commit at d54b1a9e and tell it the result
of the test.  The message says "0 left to test *after* this";
doesn't it mean you still need to do *this*?

A bisecct session ends when it tells you

	XXXXXX is the first bad commit

which I do not see in the above.  You seem to have stopped before
that happens.

Looks perfectly normal to me.  The message above:

quoted

HEAD is now at a0d271c... Linux 3.6
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[d54b1a9e0eaca92cde678d19bd82b9594ed00450] perf script: Remove use of die/exit

is asking you to test the commit at d54b1a9e and tell it the result
of the test.  The message says "0 left to test *after* this";
doesn't it mean you still need to do *this*?

A bisecct session ends when it tells you

	XXXXXX is the first bad commit

which I do not see in the above.  You seem to have stopped before
that happens.

Yes, I should do one more step.  Thanks for catching.

Tim