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.
next prev 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).