Re: RFE: "git bisect reverse"

[Ealdwulf Wuffinga <ealdwulf@googlemail.com>]

>> 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?

The reason I ask is that I am wondering how this feature might be
implemented in bbchop
(http://github.com/Ealdwulf/bbchop/tree/master) which is an extension
of git-bisect
to the case where the bug is intermittent. It works by calculating the
probability that the
bug was introduced at each commit, and asking about that commit which
has the largest
expected information gain. Currently if there is a skip I just set the
probability
for that commit to zero, so the algorithm is likely to ask next about
an adjacent one,
just as in git-bisect. A natural way to extend bbchop to this use case
would be for
the information gain calculation to take into account the probability
that a commit is broken.

So I would need some plausible way of calculating that probability. It
is not immediately
obvious to me what that would be, or what assumptions would be useful.

Ealdwulf