Christian Couder <chriscool@xxxxxxxxxxxxx> writes: > Another idea to fix the problem, might be to bisect as usual and at the end > before saying "X is first bad commit" to check if some of X parents are > merge bases between the bad rev and a good rev. If that is the case, then > we could ask the user to check that these parents are all good. On average > this would probably reduce the number of revs the user must check. I do not think that would fly well. After spending long bisection cycle, you will be telling the user that it was a wild goose chase (iow, the user did an invalid bisection and what we stopped at was not the first breakage). If the bisection topology is invalid, we should tell the user before he wastes too much time. The sad part is that the biesction log from such an initial round would not be very useful for reusing even if the user then chooses to hunt for the "fix" on the side branch to forward port, in which case the meaning of good and bad needs to be swapped from the beginning. -- 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
