Florian Bruhin <[email protected]> writes: > * 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.
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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
