Re: RFC: reverse bisect

From: Jeff King <peff@peff.net>
Date: Sep 30, 2011, 04:09 UTC
Message-ID: <20110930040924.GA28724@sigill.intra.peff.net>
In-Reply-To: <4E849C5B.7050201@kdbg.org>

On Thu, Sep 29, 2011 at 06:27:07PM +0200, Johannes Sixt wrote:

Show 7 quoted lines

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