From: Florian Bruhin <me@the-compiler.org>
Date: Mon, 14 Dec 2015 18:22:55 GMT
Subject: Re: git bisect with temporary commits
Message-ID: <20151214182255.GB13519@tonks>
In-Reply-To: <87si34hphr.fsf@igel.home>

* Andreas Schwab <schwab@linux-m68k.org> [2015-12-14 19:08:48 +0100]:
> 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.

I see - but wouldn't it make more sense for a "git bisect good" (or
bad, respectively) without arguments to assume I mean the commit
bisect checked out for me, not HEAD?

I don't see any scenario where the current behaviour would make sense,
but I might be missing something.

Florian

-- 
http://www.the-compiler.org | me@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/