Junio C Hamano <gitster@xxxxxxxxx> writes: > Christian Couder <chriscool@xxxxxxxxxxxxx> writes: > >> Before this patch "git bisect" doesn't really work when it is given >> some good revs that are siblings of the bad rev. >> >> For example if there is the following history: >> >> A-B-C-D >> \E-F >> >> and we launch "git bisect start D F" then only C and D will be >> considered as possible first bad commit. This is wrong because A, B and >> E may be bad too if the bug exists everywhere except in F that fixes it. > > Please don't. > > bisect is about finding a single regression by partitioning the graph into > older good section and newer bad section with a *single* "first bad > commit". > > Your "this could also be possible" scenario is already outside the > realm. You are assuming A, B and F is good, and D is bad. But if E is > bad, then that breakage cannot possibly affect the transition between B > and D from good to bad (E cannot break D), so C must *also* be bad. ... which means you are dealing with *two* breakages. That's outside what bisect deals with. And this does not need to have forked development. If the graph were like this: A-B-C-D-E-F and if F is bad and B is good, with your logic, after checking that D is already bad, we cannot discount E --- after somehow fixing D, we _might_ also be introducing another breakage with E. You cannot even check for that anyway, but the logic is the same. -- 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
