git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: david@lang.hm
Cc: Christian Couder <chriscool@tuxfamily.org>,
	git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Andreas Ericsson <ae@op5.se>, Jeff Garzik <jeff@garzik.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Bill Lear <rael@zopyra.com>, Jon Seymour <jon.seymour@gmail.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: Article about "git bisect run" on LWN
Date: Fri, 6 Feb 2009 02:52:15 +0100	[thread overview]
Message-ID: <20090206015215.GA6261@elte.hu> (raw)
In-Reply-To: <20090206014655.GA26807@elte.hu>


* Ingo Molnar <mingo@elte.hu> wrote:

> The idea would be to insert 30% redunancy into my bisections automatically 
> - so that i could trust _all_ bisections more - not just the ones i 
> suspect to be non-deterministic. Hence the suggestion to enable lower 
> levels of redundancy like 30%. (but even 10% or 20% might be enough to 
> weed out the most obvious cases)

the other advantage of redundancy that i forgot to mention:

- Sometimes the non-determinism is inserted by a _human_. It happened not
  once that i accidentally mis-judged a testpoint, and the bisection ran
  afoul. Only 4-5 steps later do i suspect that something is wrong: that i 
  get an unlikely series of good,good,good,good,good or bad,bad,bad,bad,bad 
  testpoint qualities.

So for manual bisection, redundancy can be a big time-saver. If i mess up a 
bisection point then say 50% redundancy can still point out my stupidity 
with a high likelyhood.

In fact if Git sees an unlikely series of same-quality bisection points, it 
could artificially insert a test to around the last-different test point, to 
test the theory of a messed up bisection.

	Ingo

  reply	other threads:[~2009-02-06  1:53 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-05  6:47 Article about "git bisect run" on LWN Christian Couder
2009-02-05 13:34 ` Bill Lear
2009-02-05 14:13 ` Ingo Molnar
2009-02-06  2:42   ` david
2009-02-06  1:46     ` Ingo Molnar
2009-02-06  1:52       ` Ingo Molnar [this message]
2009-02-06  5:23   ` Christian Couder
2009-02-07  4:41     ` Christian Couder
2009-02-07 12:55       ` David Symonds
2009-02-07 18:09         ` Christian Couder
2009-02-07 18:16         ` Junio C Hamano
2009-02-09 12:19           ` Ingo Molnar
2009-02-09 13:15             ` Johannes Schindelin
2009-02-09 21:03               ` David Symonds
2009-02-10  6:12                 ` Christian Couder
2009-02-05 16:23 ` Jonathan Corbet
2009-02-05 20:54   ` Christian Couder
2009-02-06  2:49   ` david

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=20090206015215.GA6261@elte.hu \
    --to=mingo@elte.hu \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=ae@op5.se \
    --cc=chriscool@tuxfamily.org \
    --cc=david@lang.hm \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jeff@garzik.org \
    --cc=jon.seymour@gmail.com \
    --cc=rael@zopyra.com \
    --cc=torvalds@linux-foundation.org \
    /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).