Junio C Hamano <gitster@xxxxxxxxx> writes:
> Christian Couder <christian.couder@xxxxxxxxx> 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@xxxxxxxxxxxxx>
>> ---
>> 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.
> 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/