From: Junio C Hamano <gitster@pobox.com>
To: Christian Couder <chriscool@tuxfamily.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Michael Haggerty <mhagger@alum.mit.edu>,
Jeff King <peff@peff.net>,
git@vger.kernel.org
Subject: Re: [PATCH] bisect: test merge base if good rev is not an ancestor of bad rev
Date: Thu, 10 Jul 2008 16:50:15 -0700 [thread overview]
Message-ID: <7vmykpmh8o.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <200807110145.33820.chriscool@tuxfamily.org> (Christian Couder's message of "Fri, 11 Jul 2008 01:45:33 +0200")
Christian Couder <chriscool@tuxfamily.org> writes:
> 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).
next prev parent reply other threads:[~2008-07-10 23:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-10 3:41 [PATCH] bisect: test merge base if good rev is not an ancestor of bad rev Christian Couder
2008-07-10 10:04 ` Johannes Schindelin
2008-07-10 19:26 ` Christian Couder
2008-07-10 20:02 ` Junio C Hamano
2008-07-10 20:13 ` Junio C Hamano
2008-07-10 22:36 ` Christian Couder
2008-07-10 22:38 ` Johannes Schindelin
2008-07-10 23:21 ` Christian Couder
2008-07-10 23:24 ` Junio C Hamano
2008-07-10 23:45 ` Christian Couder
2008-07-10 23:50 ` Junio C Hamano [this message]
2008-07-10 23:59 ` Johannes Schindelin
2008-07-11 6:51 ` Junio C Hamano
2008-07-11 11:21 ` Johannes Schindelin
2008-07-10 23:10 ` Junio C Hamano
2008-07-13 6:37 ` Christian Couder
2008-07-13 13:14 ` Johannes Schindelin
2008-07-22 6:15 ` Christian Couder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vmykpmh8o.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=mhagger@alum.mit.edu \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).