From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Christian Couder <chriscool@tuxfamily.org>
Cc: Junio C Hamano <gitster@pobox.com>,
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 12:04:35 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.1.00.0807101201210.3135@eeepc-johanness> (raw)
In-Reply-To: <20080710054152.b051989c.chriscool@tuxfamily.org>
Hi,
On Thu, 10 Jul 2008, Christian Couder wrote:
> Before this patch, "git bisect", when it was given some good revs that
> are not ancestor of the bad rev, didn't check if the merge bases were
> good. "git bisect" just supposed that the user knew what he was doing,
> and that, when he said the revs were good, he knew that it meant that
> all the revs in the history leading to the good revs were also
> considered good.
Well, it is not completely relying on the user.
The common scenario before a bisect is this: something used to work _all
the time_, and all of a sudden, it does not anymore.
So it is expected that there is no fix in the history. Not in the current
branch, not in the "good" branch, not wherever.
In that case, you are literally guaranteed that all ancestors of a good
commit are good, too, because if there was a bad one, there would be a
fix, too.
The whole idea of "bisect" relies on that idea, that any ancestor of a
good commit is good. Otherwise you'd have to check the commits one by
one, not in a bisecting manner.
Ciao,
Dscho
next prev parent reply other threads:[~2008-07-10 10:05 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 [this message]
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
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=alpine.DEB.1.00.0807101201210.3135@eeepc-johanness \
--to=johannes.schindelin@gmx.de \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--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