Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html