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

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Christian Couder <chriscool@tuxfamily.org> writes:
>
>> Le mardi 1 juillet 2008, Junio C Hamano a écrit :
>>> 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.
>>
>> I am assuming the first bad commit in the graph is A and it is fixed by F.
>
> Ah, I see your confusion here.  bisect is about finding regressions.
> "Older ones were good, and now there is a breakage.  Who broke it?"
>
> If F fixed it, that is already outside the bisection's scope.  The user
> needs to know that by saying F is good, he is saying he knows everything
> that leads to F is good.

Ok, I wasn't thinking straight.

The tricky part is that the user does not know.

Until we somehow can check B is bad, we cannot tell that the original
bisection was done incorrectly (in the sense that it was not finding
regression, but what the user could find is which commit fixed it).

If we perform a test merge between D and F and test that tree, and if that
turns out to be Ok, that would be a good indication of existence of a fix
(i.e. the topology is not "old good code was broken somewhere", but "old
broken code was fixed somewhere").  I am not sure how applicable that
approach would be in practice, though.