* Andreas Schwab <[email protected]> [2015-12-14 19:08:48 +0100]: > Florian Bruhin <[email protected]> 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 | [email protected] (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/
signature.asc
Description: Digital signature
