Re: Why can't I use git-bisect to find the first *good* commit?
- From
Matthieu Moy <matthieu.moy@grenoble-inp.fr>
- Date
- Mar 28, 2011, 20:37 UTC
- Message-ID
- <vpqvcz3x9q0.fsf@bauges.imag.fr>
- In-Reply-To
- <AANLkTim+iQ89b49nC8NRtoUobV4tMVL+bCoW-vg3+rLD@mail.gmail.com>
Andrew Garber <andrew@andrewgarber.com> writes:
Show 8 quoted lines
> 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/