Re: should "git bisect" support "git bisect next?"

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

Theodore Ts'o <tytso@mit.edu> writes:

> On Sun, Nov 12, 2017 at 03:21:57PM +0100, Christian Couder wrote:
>> 
>> Yeah I agree that it might be something interesting for the user to do.
>> But in this case the sequence in which you give the good and the bad
>> commits is not important.
>> Only the last bad commit and the set of good commits that were given
>> are important.
>
> Is it really true that of the bad commits, only the last one is significant?
>
> Suppose we have a git tree that looks like this:
>
>           *---*---*---*---*---*---M2---*---B1
>           |                        |
>   G1--*--D1---*---*---*---B2-\     |
>           |                   \    /
>           *---*---*---B3--*---M1--/
>
> If we know that commits B2 and B3 are bad, if we assume that all
> commits before the "bad" commit are good, all commits after the "bad"
> commit are bad, can we not deduce that commit D1 should also be "bad"?

You are correct.  Christian fell into an understandable and common
confusion.  It is true that we only maintain one significant bad
(i.e. the breakage that is known-ealiest so far), but that oldest
bad is the result of the bisection taking into account all the 'bad'
we have got in sequence so far, not necessarily the same as, and
hopefully way better than, the last bad the user gave from the
command line.  In your topology, "git bisect log" would contain "bad
B1", "bad B2", and "bad B3", and when the earlier session that
produced that log saw these three bad commits, it would have marked
D1 as the known-earliest bad one.

Taking the last-given bad B3 is suboptimal than that.