Re: [PATCH] bisect: error out when given any good rev that is not an ancestor of the bad rev

From: Christian Couder <chriscool@tuxfamily.org>
Date: Jun 30, 2008, 23:16 UTC
Message-ID: <200807010116.30214.chriscool@tuxfamily.org>
In-Reply-To: <7v3amuv8yg.fsf@gitster.siamese.dyndns.org>

Le mardi 1 juillet 2008, Junio C Hamano a écrit :

Show 22 quoted lines

> Christian Couder <chriscool@tuxfamily.org> 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".
>
> For 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.

I am assuming the first bad commit in the graph is A and it is fixed by F.

> 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.

Yes, I assume C is also bad.

> ... which means you are dealing with *two* breakages.  That's outside
> what bisect deals with.

Sorry, I don't understand why I am assuming 2 breakages.

Show 9 quoted lines

> 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.

I don't think the logic is the same because in your case git bisect will report one first bad commit anyway even if this bad commit has been fixed latter.

In my case above, git bisect currently considers C and D as the only possible bad commits because when it is told that F is good, it assumes that all the ancestors or F are good too. And this means that B is considered good so C will be found as the first bad commit. I think this can be really misleading because there is no good->bad transition between B and C.

Regards, Christian.