From: Junio C Hamano <gitster@pobox•com>
To: Florian Bruhin <me@the-compiler•org>
Cc: Andreas Schwab <schwab@linux-m68k•org>,
git@vger•kernel.org, r.seitz@beh•ch
Subject: Re: git bisect with temporary commits
Date: Mon, 14 Dec 2015 11:21:06 -0800 [thread overview]
Message-ID: <xmqqa8pckfa5.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20151214182255.GB13519@tonks> (Florian Bruhin's message of "Mon, 14 Dec 2015 19:22:55 +0100")
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.
next prev parent reply other threads:[~2015-12-14 19:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-14 16:37 git bisect with temporary commits Florian Bruhin
2015-12-14 18:08 ` Andreas Schwab
2015-12-14 18:22 ` Florian Bruhin
2015-12-14 19:21 ` Junio C Hamano [this message]
2015-12-14 19:38 ` Florian Bruhin
2015-12-14 20:17 ` Andreas Schwab
2015-12-14 21:09 ` Jeff King
2015-12-14 21:17 ` Junio C Hamano
2015-12-14 21:26 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqa8pckfa5.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=me@the-compiler$(echo .)org \
--cc=r.seitz@beh$(echo .)ch \
--cc=schwab@linux-m68k$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox