Re: [PATCH] bisect: test merge base if good rev is not an ancestor of bad rev

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 10, 2008, 23:50 UTC
Message-ID: <7vmykpmh8o.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <200807110145.33820.chriscool@tuxfamily.org>

Christian Couder <chriscool@tuxfamily.org> writes:

Show 29 quoted lines

> Le vendredi 11 juillet 2008, Junio C Hamano a écrit :
>>
>>     (2)       Good
>>           ?---o (maint)
>>          /
>>      ---x---?---?---?---x (master)
>>         Bad             Bad
>>
>>
>> If (1), you go ahead with the usual bisection.  If (2), you cannot even
>> bisect.  Instead, you flip good and bad to find the "fix" in the side
>> branch (the answer has to be either the tip of maint or one previous in
>> the picture) to forward port to, either by merging 'maint' to 'master' or
>> cherry-picking.
>>
>> The idea to check merge-base first is about automating this process (I
>> admit I still haven't looked at Christian's patch text yet).
>
> Well in case (2) my patch does:
>
> -------
> 		cat >&2 <<EOF
> The merge base $_badmb is bad.
> This means the bug has been fixed between $_badmb and $_g.
> EOF
> 		exit 3
> -------
>
> but this can be improved upon in some latter patches.

I think such an "improvement" is getting close to being too clever. I should have worded my description on what you would do in (2) a bit more carefully.

    If (2), you cannot even bisect.

    Instead, you may decide to merge 'maint' to 'master' to get that fix.
    In which case you do not have to worry about it; you do not do
    anything further.

    If you cannot afford to merge 'maint' to 'master' but somehow need to
    forward port the fix by cherry-picking, you need to flip good and bad
    to find the "fix" in the side branch (the answer has to be either the
    tip of maint or one previous in the picture).