From: Junio C Hamano Date: Mon, 14 Dec 2015 19:21:06 GMT Subject: Re: git bisect with temporary commits Message-ID: In-Reply-To: <20151214182255.GB13519@tonks> 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.