> Suppose you have a bug in git.git that you see in pu, but not in next. > Try finding the common ancestor with your command, and see how long it > takes. Fair enough. > Yes, you'll be able to do it, but you still didn't tell us what was > wrong with > > git bisect start > git bisect good origin/next > git bisect bad origin/pu > ... > > which is _way_ faster. And my example took git.git which isn't a very > large project, so real-life examples could be much worse. 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. -- 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