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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 28, 2011 at 04:25:21PM -0400, Jeff King wrote:

> On Mon, Mar 28, 2011 at 04:12:49PM -0400, Andrew Garber wrote:
> 
> > 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

Actually, scratch what I said. I misread his graph. The fix has not yet
been cherry-picked, it just exists on the other branch. So there is no
flipping. But as Matthieu explained in another response, there is still
value in bisecting that graph.

-Peff
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]