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: Christian Couder <christian.couder@gmail.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	git@vger.kernel.org, Sam Vilain <sam@vilain.net>,
	Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH v3 0/3] automatically skip away from broken commits
Date: Thu, 11 Jun 2009 06:02:54 +0200	[thread overview]
Message-ID: <200906110602.54861.chriscool@tuxfamily.org> (raw)
In-Reply-To: <7vtz2nlrfs.fsf@alter.siamese.dyndns.org>

Le Wednesday 10 June 2009, Junio C Hamano a écrit :
> Christian Couder <christian.couder@gmail.com> writes:
> > On Tue, Jun 9, 2009 at 10:37 PM, Junio C Hamano<gitster@pobox.com> 
wrote:
> >> Christian Couder <christian.couder@gmail.com> writes:
> >>> My opinion is that we should not penalize all the people working on
> >>> "quite clean" projects and also people working on "not clean"
> >>> projects who are able to recover, on the pretence that there are
> >>> other people on these "not clean" projects who are not.
> >
> > ...
> > When I wrote "clean", I just mean with not too many untestable commits.
>
> Ok, then the "opinion" in the above paragraph was simply stating the
> obvious: we should have a good "bisect skip".  I obviously agree with
> that ;-).
>
> In other words, you were not arguing against my observation that your
> algorithm would not be much better than randomly picking the next commit
> when the best one is untestable, unless the history is linear.

I think my algorithm is better enough than a random one to be worth using by 
default. Like HPA says it's in practice like a random one with a bias.

That's because the "goodness" value is something that has a relationship 
with the graph topology. The "goodness" value is some kind of distance from 
either the good or the bad commits. The farther from the good and bad 
commits the higher is the "goodness" value. And my algorithm tries to avoid 
commits with low "goodness" value because they should be those near the 
good and bad commits and we know that those near the good and bad commits 
wont give a lot of information.

> I guess 
> that was what I was confused with.  I thought you were saying that we
> should give preferential treatment to people with linear history.
>
> > Ok. I started working on optionaly using a PRNG but I am not sure that
> > you will want to add another one.
>
> It may still make sense to replace, not add to, that "fixed alternating
> distance in goodness space" with a randomized one, for the reasons HPA
> stated, especially for avoiding to give a false impression that the magic
> constants are picked for some reason.

But there _is_ a reason.

Best regards,
Christian.

  parent reply	other threads:[~2009-06-11  4:03 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-06  4:41 [PATCH v3 0/3] automatically skip away from broken commits Christian Couder
2009-06-06  4:41 ` [PATCH v3 1/3] bisect: add parameters to "filter_skipped" Christian Couder
2009-06-06  4:41 ` [PATCH v3 2/3] bisect: when skipping, choose a commit away from a skipped commit Christian Couder
2009-06-06  4:41 ` [PATCH v3 3/3] t6030: test skipping away from an already " Christian Couder
2009-06-06 19:51 ` [PATCH v3 0/3] automatically skip away from broken commits Junio C Hamano
2009-06-07  7:32   ` Christian Couder
2009-06-08  6:06     ` H. Peter Anvin
2009-06-08  7:25       ` Junio C Hamano
2009-06-08 15:51         ` H. Peter Anvin
2009-06-08 21:02           ` Junio C Hamano
2009-06-08 21:10             ` H. Peter Anvin
2009-06-09  4:24             ` Christian Couder
2009-06-09 10:02               ` Jakub Narebski
2009-06-09 15:11                 ` H. Peter Anvin
2009-06-09 21:55                   ` Jakub Narebski
2009-06-09 22:54                     ` H. Peter Anvin
2009-06-09 12:26               ` Christian Couder
2009-06-09 15:25                 ` H. Peter Anvin
2009-06-09 18:35                   ` Junio C Hamano
2009-06-09 18:42                     ` H. Peter Anvin
2009-06-09 19:28                   ` Christian Couder
2009-06-09 19:32                     ` H. Peter Anvin
2009-06-10  8:14                       ` Christian Couder
2009-06-09 20:37                     ` Junio C Hamano
2009-06-10 19:37                       ` Christian Couder
2009-06-10 21:17                         ` Junio C Hamano
2009-06-10 22:43                           ` H. Peter Anvin
2009-06-11  4:02                           ` Christian Couder [this message]
2009-06-11  4:43                             ` H. Peter Anvin
2009-06-11  5:05                               ` H. Peter Anvin
2009-06-12 11:56                                 ` Christian Couder
2009-06-13 19:03                                   ` H. Peter Anvin
2009-06-13 19:35                                     ` Jakub Narebski
2009-06-13 19:57                                       ` H. Peter Anvin
2009-06-15  7:59                                     ` Christian Couder
2009-06-15 13:16                                       ` H. Peter Anvin
2009-06-13  7:50     ` 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=200906110602.54861.chriscool@tuxfamily.org \
    --to=chriscool@tuxfamily.org \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hpa@zytor.com \
    --cc=mingo@elte.hu \
    --cc=sam@vilain.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).