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