On Mon, Dec 14, 2015 at 07:08:48PM +0100, Andreas Schwab wrote: > Florian Bruhin <me@xxxxxxxxxxxxxxxx> 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. Another alternative is to use "git cherry-pick -n" to create a working tree state that you can test, but leave HEAD at the original commit. Then "git bisect good" does the right thing. It's the same principle and I don't think there is a reason to prefer one over the other. I just find it harder to screw up, as I usually script the build/test, so I can stick the cherry-pick there and not have to remember it on each "good/bad" report. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html