From: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Date: Mon, 28 Mar 2011 20:37:27 GMT
Subject: Re: Why can't I use git-bisect to find the first *good* commit?
Message-ID: <vpqvcz3x9q0.fsf@bauges.imag.fr>
In-Reply-To: <AANLkTim+iQ89b49nC8NRtoUobV4tMVL+bCoW-vg3+rLD@mail.gmail.com>

Andrew Garber <andrew@andrewgarber.com> writes:

> But what about demerphq's example? (see below)
>
>>      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/