Re: RFE: "git bisect reverse"
- From
- Ealdwulf Wuffinga <ealdwulf@googlemail.com>
- Date
- May 31, 2009, 22:18 UTC
- Message-ID
- <efe2b6d70905311518w4c2d79ecy8cdabd15a8effc7c@mail.gmail.com>
- In-Reply-To
- <4A1F07FA.6040008@zytor.com>
On Thu, May 28, 2009 at 10:54 PM, H. Peter Anvin <hpa@zytor.com> wrote:
Show 6 quoted lines
> How about simply modelling it linearly, with 100% probability for known > skip point, 0% for a known good/bad point, and a linear gradient in > between? It's probably a good enough model. In practice, it will > vastly overestimate the probability of a skip, so if a linear model > turns out to be too conservative, I would probably just try to model it > as a higher-order power function.
Sounds plausible. It's not obvious how to generalise it to a DAG, though.
What's easier to implement is simple geometric decay (from a probability of 1 at the commit of an actual skip). It even has a plausible rationale - the probability that someone notices the brokenness and fixes it is probably a constant, which would lead to geometric decay. That probably doesn't reflect what happens when someone breaks a whole swath of stuff retrospectively somehow, though.
I've implemented geometric (and arithmetic) decay in bbchop, with a configurable decay factor. With a factor sufficiently close to one (eg, 0.99) it can be persuaded to hop a reasonable distance, which seems to scale to a certain extent with the number of commits left, so hopefully it won't be necessary to fiddle with the factor a lot.
http://github.com/Ealdwulf/bbchop/tree/master
Ealdwulf