Re: Why can't I use git-bisect to find the first *good* commit?
- From
Jeff King <peff@peff.net>
- Date
- Mar 28, 2011, 20:25 UTC
- Message-ID
- <20110328202521.GB27755@sigill.intra.peff.net>
- In-Reply-To
- <AANLkTim+iQ89b49nC8NRtoUobV4tMVL+bCoW-vg3+rLD@mail.gmail.com>
On Mon, Mar 28, 2011 at 04:12:49PM -0400, Andrew Garber wrote:
Show 15 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? > > > > Presumably 'By' broke the G* branch which was then fixed by Gx and > > none of this information helps you at all identify that Bx broke the > > B* branch. > > > > Whereas a plain binary search on the B* branch would eventually find > > that Bx was responsible.
If you feed bisect a history where the bug flips off and on between good and bad commits, you aren't necessarily going to get the answer you want. But that has nothing to do with the history shape; it is a problem in a linear history like this, too:
--G--Bx--B--G--G--By--B
That being said, it is more likely to happen with cherry-picking, which is more likely to happen with multiple branches. In git.git, we tend to favor creating (or backporting) bugfix commits close to the bug itself, and then merging the same commit up.
-Peff