On Wed, May 27, 2009 at 10:11:35PM +0100, Ealdwulf Wuffinga wrote: > >> Sam Vilain wrote: > >> > Oh, yes. And another thing: 'git bisect run' / 'git bisect skip' > >> > doesn't do a very good job of skipping around broken commits (ie when > >> > the script returns 126). It just seems to move to the next one; it > >> > would be much better IMHO to first try the commit 1/3rd of the way into > >> > the range, then if that fails, the commit 2/3rd of the way through it, > >> > etc. > > As I understand it, the idea is that the probability that a commit is > broken is greater if it is close in the DAG to a known-broken commit. > I wonder if this can be made more concrete? Can we derive a formula > for, or collect empriical data on, these probabilities? No. The idea is that we want to reduce to bisect as close to the middle as possible so we only have to do log2(n) tests. But if a commit is skipped, that means we cannot decide whether the test passes or fails for this commit. But if we choose a commit close to the skipped one, we will likely have to skip the that one for the same reason. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html