Re: RFE: "git bisect reverse"

From: Ealdwulf Wuffinga <ealdwulf@googlemail.com>
Date: May 27, 2009, 21:11 UTC
Message-ID: <efe2b6d70905271411g4e1616b5w548141ee9fab2c14@mail.gmail.com>
In-Reply-To: <200905270726.59883.chriscool@tuxfamily.org>

Show 7 quoted lines

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