git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Couder <chriscool@tuxfamily.org>
To: Junio C Hamano <gitster@pobox.com>
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: Fri, 11 Jul 2008 00:36:17 +0200	[thread overview]
Message-ID: <200807110036.17504.chriscool@tuxfamily.org> (raw)
In-Reply-To: <7vd4llpkxq.fsf@gitster.siamese.dyndns.org>

Le jeudi 10 juillet 2008, Junio C Hamano a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
> > Yeah, in that case...
> >
> >> 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.
>
> Didn't we already discuss this at length?

Yes, the thread is there:

http://thread.gmane.org/gmane.comp.version-control.git/86951

> > No, you just need to check that the merge bases between the bad rev on
> > one side and each good rev on the other side are good too. And if that
> > is the case, then you can be sure that bisection will point to a first
> > bad commit.
> >
> > So the choice is between a simple and fast but not fully reliable
> > bisect, or a more complex and slower but fully reliable bisect.
>
> I have not looked at your implementation, but I do think:
>
>  - The current one is not "fully reliable"; the user needs to know what
>    he is doing.  You might call it "prone to user errors".

I agree.

>  - "Test this merge-base before going forward, please" will add typically
>    only one round of check (if you have more merge bases between good and
>    bad, you need to test all of them are good to be sure), so it is not
>    "slower nor more complex".

By "slower" I meant that it would need more rounds of check on average.
By "more complex" I meant that more code is needed.

And I think you are right, all the merge bases need to be tested so I will 
send a patch on top of the patch discussed here.

Another idea to fix the problem, might be to bisect as usual and at the end 
before saying "X is first bad commit" to check if some of X parents are 
merge bases between the bad rev and a good rev. If that is the case, then 
we could ask the user to check that these parents are all good. On average 
this would probably reduce the number of revs the user must check.

Regards,
Christian.

 

  parent reply	other threads:[~2008-07-10 22:33 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 [this message]
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=200807110036.17504.chriscool@tuxfamily.org \
    --to=chriscool@tuxfamily.org \
    --cc=Johannes.Schindelin@gmx.de \
    --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;
as well as URLs for NNTP newsgroup(s).