Tim Chen <tim.c.c...@linux.intel.com> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
