Andrew Garber <andrew@xxxxxxxxxxxxxxxx> writes: > 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/ -- 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