Re: git bisect with temporary commits

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 14, 2015, 19:21 UTC
Message-ID: <xmqqa8pckfa5.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20151214182255.GB13519@tonks>

Florian Bruhin <me@the-compiler.org> writes:

Show 23 quoted lines

> * Andreas Schwab <schwab@linux-m68k.org> [2015-12-14 19:08:48 +0100]:
>> Florian Bruhin <me@the-compiler.org> 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.