From: Jeff King <peff@peff.net>
Date: Mon, 14 Dec 2015 21:09:36 GMT
Subject: Re: git bisect with temporary commits
Message-ID: <20151214210936.GD14788@sigill.intra.peff.net>
In-Reply-To: <87si34hphr.fsf@igel.home>

On Mon, Dec 14, 2015 at 07:08:48PM +0100, Andreas Schwab wrote:

> Florian Bruhin <me@the-compiler.org> writes:
> 
> > Now when trying to say it's good (and forgetting to remove the
> > temporary commits), I get this:
> >
> >     $ git bisect good
> >     Bisecting: a merge base must be tested
> >     [981e1093dae24b37189bcba2dd848b0c3388080c] still good and does not compile
> >
> > Is this intended behaviour? Shouldn't git either do a reset to the
> > commit we're currently bisecting, or warn the user as it was probably
> > unintended to add new commits?
> 
> You should instead tell git that HEAD^ is good, since that is what git
> asked you to test.

Another alternative is to use "git cherry-pick -n" to create a working
tree state that you can test, but leave HEAD at the original commit.
Then "git bisect good" does the right thing.

It's the same principle and I don't think there is a reason to prefer
one over the other. I just find it harder to screw up, as I usually
script the build/test, so I can stick the cherry-pick there and not have
to remember it on each "good/bad" report.

-Peff