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,
Linus Torvalds <torvalds@linux-foundation•org>
Subject: Re: [PATCH] bisect: error out when given any good rev that is not an ancestor of the bad rev
Date: Mon, 30 Jun 2008 16:52:00 -0700 [thread overview]
Message-ID: <7vej6etra7.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <200807010146.09206.chriscool@tuxfamily.org> (Christian Couder's message of "Tue, 1 Jul 2008 01:46:09 +0200")
Christian Couder <chriscool@tuxfamily•org> writes:
> Yes, but the fact is that the user may wrongly think that F is an ancestor
> of D or he may not remember/know about the rule that saying "F is good"
> means "everything from A to F is good". That's why this patch adds a safety
> net by detecting end erroring out in this case.
Yeah, sorry about the confusion earlier.
But I do not think forbidding forked topology very early in bisection
process is a very good idea. The user would be at loss when told:
echo >&2 "Maybe you mistake good and bad revs?"
Aside from the "test a trial merge" idea I floated in the other message,
when we detect such a fork, perhaps we can suggest testing the merge base
version (B in your picture) first? We would immediately know as the user
would say "B is bad" if the topology is problematic.
Then, we can suggest the user that breakage at D may not be a regression
but a longstanding bug that was recently fixed somewhere between B and F.
The user then can decide to bisect to find the fix (so that it can be
cherry picked on top of D) or merge F into D to propagate the fix forward
if it is not important to find out which exact commit fixed the issue.
Hmm?
next prev parent reply other threads:[~2008-06-30 23:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-30 22:42 [PATCH] bisect: error out when given any good rev that is not an ancestor of the bad rev Christian Couder
2008-06-30 22:44 ` Junio C Hamano
2008-06-30 22:48 ` Junio C Hamano
2008-06-30 23:16 ` Christian Couder
2008-06-30 23:27 ` Junio C Hamano
2008-06-30 23:32 ` Junio C Hamano
2008-06-30 23:42 ` Junio C Hamano
2008-06-30 23:46 ` Christian Couder
2008-06-30 23:52 ` Junio C Hamano [this message]
2008-07-01 0:20 ` Christian Couder
2008-07-01 1:13 ` Junio C Hamano
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=7vej6etra7.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox$(echo .)com \
--cc=Johannes.Schindelin@gmx$(echo .)de \
--cc=chriscool@tuxfamily$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=mhagger@alum$(echo .)mit.edu \
--cc=peff@peff$(echo .)net \
--cc=torvalds@linux-foundation$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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