Hi, On Thu, 10 Jul 2008, Christian Couder wrote: > Before this patch, "git bisect", when it was given some good revs that > are not ancestor of the bad rev, didn't check if the merge bases were > good. "git bisect" just supposed that the user knew what he was doing, > and that, when he said the revs were good, he knew that it meant that > all the revs in the history leading to the good revs were also > considered good. Well, it is not completely relying on the user. The common scenario before a bisect is this: something used to work _all the time_, and all of a sudden, it does not anymore. So it is expected that there is no fix in the history. Not in the current branch, not in the "good" branch, not wherever. In that case, you are literally guaranteed that all ancestors of a good commit are good, too, because if there was a bad one, there would be a fix, too. The whole idea of "bisect" relies on that idea, that any ancestor of a good commit is good. Otherwise you'd have to check the commits one by one, not in a bisecting manner. Ciao, Dscho -- 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
