Re: git bisect with temporary commits

[Florian Bruhin <me@the-compiler.org>]

[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]

* Junio C Hamano <gitster@pobox.com> [2015-12-14 11:21:06 -0800]:
> Florian Bruhin <me@the-compiler.org> writes:
> 
> > * 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.

That makes sense - thanks for the explanation!

Florian

-- 
http://www.the-compiler.org | me@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]