On Thu, Sep 29, 2011 at 06:27:07PM +0200, Johannes Sixt wrote: > > git bisect good/bad/skip/run > > Last time this came up on the list I suggested to add the following > commands: > > git bisect regression # a synonym for git bisect start > git bisect improvement # your --reverse That makes some sense to me. But I do wonder if you could simply get rid of the connotations of "good" and "bad" entirely, by thinking of it as simply looking for a commit that introduced some property. Like: # find a bug git bisect start git bisect yes ;# has the bug git bisect no ;# does not have the bug git bisect skip ;# no idea # find a feature being implemented git bisect start git bisect yes ;# has the feature git bisect no ;# does not have the feature git bisect skip ;# no idea IOW, I feel like we are having to handle this weird negation only because we have assigned a value judgement to the tests. That instead of saying "yes, we have this bug", we say "bad", which only makes sense if you are looking for a bad thing. You can still produce a negation in your mind, of course, by asking "when did this property go away". But that is usually about a bug being fixed, so the right answer is generally not a set of command line options, but to stop asking "when did bug X go away", and instead ask "when did the fix for bug X appear". One catch is that the run command assumes a successful exit is "good", and anything else is "bad". Which makes: git bisect run make test good for finding regressions, but is a little counterintuitive for the yes/no thing (a successful exit means "no"). -Peff -- 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