From: "H. Peter Anvin" <hpa@zytor.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Christian Couder <chriscool@tuxfamily.org>,
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: Mon, 08 Jun 2009 08:51:24 -0700 [thread overview]
Message-ID: <4A2D337C.70203@zytor.com> (raw)
In-Reply-To: <7vws7n6vcf.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>> It's not entirely clear to me that this is any better than simply
>> randomly picking a commit from the list of plausible commits -- in other
>> words, eliminate the commits we can totally rule out, and then just pick
>> a random commit among the list of plausible commits. This is not
>> *quite* as crazy as it sounds; it has the advantage of being an
>> extremely simple algorithm which shouldn't have any pathological behaviours.
>
> That is essentially what Christian's patch does. It does not try to go
> away from untestable commits in topological space. Instead, when we find
> that the commit with the best "goodness" value is known to be untestable,
> we step away from that commit by some alternating distance _in the
> goodness value space_ (which does not have much to do with how commit
> ancestry topology is laid out). Viewed in the topology space, it is quite
> similar to picking a different commit randomly, except for a very special
> case where the remaining history is completely linear, in which case the
> goodness value space and ancestry topology have a direct correlation.
>
> That special case, and the deterministic hence repeatable nature of the
> algorithm, are the two main advantages over picking a completely random
> commit among the list of plausible commits.
Well, the cyclic "stepping distance" is pretty much a really lame PRNG
in this case. In the linear case I think the distances are rather
arbitrary (and suboptimal), and I'm not sure it wouldn't simply be
better to actually use a PRNG (which can be unseeded and therefore
repeateable, or perhaps even better seeded with some combination of the
hash values involved.)
The advantage of that -- and I have to admit I don't know if it will
ever matter in practice -- is that using an actual PRNG:
a) is less likely to get into pathological capture behaviors.
b) doesn't make people think later that there is something magic to the
arbitrary chosen numbers.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
next prev parent reply other threads:[~2009-06-08 19:29 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 [this message]
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
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=4A2D337C.70203@zytor.com \
--to=hpa@zytor.com \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.