From: Florian Bruhin Date: Mon, 14 Dec 2015 19:38:02 GMT Subject: Re: git bisect with temporary commits Message-ID: <20151214193802.GD13519@tonks> In-Reply-To: * Junio C Hamano [2015-12-14 11:21:06 -0800]: > Florian Bruhin writes: > > > * Andreas Schwab [2015-12-14 19:08:48 +0100]: > >> Florian Bruhin 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. > > When the commit "bisect" checked out is untestable, the user can > freely go to another commit, e.g. "git reset --hard HEAD^" to go > back one step, and then test it instead. "git bisect good" has > to mark the then-current HEAD, not the commit that was checked out, > for this to work. That makes sense - thanks for the explanation! 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/