From: Junio C Hamano Date: Mon, 30 Jun 2008 22:48:49 GMT Subject: Re: [PATCH] bisect: error out when given any good rev that is not an ancestor of the bad rev Message-ID: <7vy74mtu7i.fsf@gitster.siamese.dyndns.org> In-Reply-To: <7v3amuv8yg.fsf@gitster.siamese.dyndns.org> Junio C Hamano writes: > Christian Couder 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.