Re: [PATCH] Documentation/bisect: improve on (bad|new) and (good|bad)

From: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Date: Jan 16, 2017, 09:17 UTC
Message-ID: <vpqfukjpdnp.fsf@anie.imag.fr>
In-Reply-To: <xmqqinpihiwz.fsf@gitster.mtv.corp.google.com>

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

Show 25 quoted lines

> Christian Couder <christian.couder@gmail.com> writes:
>
>> The following part of the description:
>>
>> git bisect (bad|new) [<rev>]
>> git bisect (good|old) [<rev>...]
>>
>> may be a bit confusing, as a reader may wonder if instead it should be:
>>
>> git bisect (bad|good) [<rev>]
>> git bisect (old|new) [<rev>...]
>>
>> Of course the difference between "[<rev>]" and "[<rev>...]" should hint
>> that there is a good reason for the way it is.
>>
>> But we can further clarify and complete the description by adding
>> "<term-new>" and "<term-old>" to the "bad|new" and "good|old"
>> alternatives.
>>
>> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
>> ---
>>  Documentation/git-bisect.txt | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> Thanks.  The patch looks good.

Looks good to me too.

> I think the answer to the question "why do we think we need a single
> bisect/bad?" is "because bisection is about assuming that there is
> only one commit that flips the tree state from 'old' to 'new' and
> finding that single commit".

I wouldn't say it's about "assuming" there's only one commit, but it's about finding *one* such commit, i.e. it works if there are several such commits, but won't find them all.

Show 11 quoted lines

> But what if bad-A and bad-B have more than one merge bases?  We
> won't know which side the badness came from.
>
>                           o---o---o---bad-A
>                          /     \ / 
>     -----Good---o---o---o       / 
>                          \     / \
>                           o---o---o---bad-B
>
> Being able to bisect the region of DAG bound by "^Good bad-A bad-B"
> may have value in such a case.  I dunno.

I could help finding several guilty commits, but anyway you can't guarantee you'll find them all as soon as you use a binary search: if the history looks like

--- Good --- Bad --- Good --- Good --- Bad --- Good --- Bad

then without examining all commits, you can't tell how many good->bad switches occured.

But keeping several bad commits wouldn't help keeping the set of potentially guilty commits small: bad commits appear on the positive side in "^Good bad-A bad-B", so having more bad commits mean having a larger DAG to explore (which is a bit counter-intuitive: without thinking about it I'd have said "more info => less commits to explore").

So, if finding all guilty commits is not possible, I'm not sure how valuable it is to try to find several of them.

OTOH, keeping several good commits is needed to find a commit for which all parents are good and the commit is bad, i.e. distinguish

Good
    \
     Bad <-- this is the one.
    /
Good

and

Good
    \
     Bad <-- need to dig further
    /
 Bad

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/