Christian Couder <chriscool@xxxxxxxxxxxxx> writes: > Yes, but the fact is that the user may wrongly think that F is an ancestor > of D or he may not remember/know about the rule that saying "F is good" > means "everything from A to F is good". That's why this patch adds a safety > net by detecting end erroring out in this case. Yeah, sorry about the confusion earlier. But I do not think forbidding forked topology very early in bisection process is a very good idea. The user would be at loss when told: echo >&2 "Maybe you mistake good and bad revs?" Aside from the "test a trial merge" idea I floated in the other message, when we detect such a fork, perhaps we can suggest testing the merge base version (B in your picture) first? We would immediately know as the user would say "B is bad" if the topology is problematic. Then, we can suggest the user that breakage at D may not be a regression but a longstanding bug that was recently fixed somewhere between B and F. The user then can decide to bisect to find the fix (so that it can be cherry picked on top of D) or merge F into D to propagate the fix forward if it is not important to find out which exact commit fixed the issue. Hmm? -- 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
