Re: RFC: reverse bisect

[Jeff King <peff@peff.net>]

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