Re: Why can't I use git-bisect to find the first *good* commit?

Andrew Garber [off-list ref] writes:

But what about demerphq's example? (see below)

quoted

     Bx--B--B--B*
    /
 --Gz--By--B--Gx--G*

How does knowing that G* is good help you to find that Bx broke the
code in the B* branch again?

If all you want is to know which commit introduced the bug, it doesn't.
But usually, what you're really looking for is an explanation and a fix
for the bug. Let's see what git bisect tells us then:

$ git bisect start
$ git bisect good <good-branch>
$ git bisect bad <bad-branch>
Bisecting: a merge base must be tested
[f1fac16fb39dbe421b5cc4bcb945433495c794e1] ...
$ git bisect bad
The merge base f1fac16fb39dbe421b5cc4bcb945433495c794e1 is bad.
This means the bug has been fixed between f1fac16fb39dbe421b5cc4bcb945433495c794e1
 and [089840ef9f8b97ddc9e28fa152c65115fb0b649a].

This doesn't tell you where the bug was introduced, but gives you
something which is usually even more valuable: where to find the fix.
Then, you have the choice between merging the good branch into the bad
one (like merging a maintainance branch into a dev branch), or to bisect
again to find the actual fix in good-branch.

If you really wanted to find the first bad commit, you've spent one
iteration sub-optimally and can start a new bisect with the merge base
as the base commit.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/