Ealdwulf Wuffinga wrote: > The question is how to avoid skips, which gain no information. You say > 'if we choose a commit close to the skipped one, we will likely have > to skip the that one'. This is what I meant by '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'. Maybe you are reading this as 'bad > commit', but this is not the sense in which Sam is using the term. > > For git-bisect, Sam and H Peter are proposing a heuristic to trade off > between information gained and likelihood of testing a bad commit. For > bbchop, I am already doing calculating the information gain directly, > so if I can incorporate the probability that a commit is broken - has > to be skipped - then the trade-off will happen automatically. > Therefore it would be useful to have some plausible theory as to how > the probability of a broken commit should be calculated, given some > known-broken and known-not-broken commits. > Sounds like interesting stuff, can you make a patch out of it? Actually it occurs to me that for projects which can successfully rebuild with just 'make' for each new revision and have a stable commit policy, walking through commits forwards like that is probably the right thing to do, because it's relatively cheap and should make progress in the lowest amount of time. So the current behaviour should probably still be available. Sam -- 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