Re: [PATCH 0/5] bisect: Add support for a --no-checkout option.

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 1, 2011, 01:00 UTC
Message-ID: <7v39hmkkth.fsf@alter.siamese.dyndns.org>
In-Reply-To: <201107301619.51438.chriscool@tuxfamily.org>

Christian Couder <chriscool@tuxfamily.org> writes:

Show 24 quoted lines

> On Saturday 30 July 2011 15:58:16 Jon Seymour wrote:
>> On Sat, Jul 30, 2011 at 11:48 PM, Christian Couder wrote:
>> > 
>> > Sorry but I didn't reply to your previous email when you asked about a
>> > "--no- checkout[=<ref>]" compromise. I thought that Junio would reply
>> > and then I forgot about it.
>> > 
>> > My opinion is that if you really want to be able to use another ref, then
>> > there should be a special "--update-ref=<ref>" or "--use-ref=<ref>"
>> > option that is different from "--no-checkout".
>> > 
>> > "--no-checkout" looks like a boolean argument. And
>> > "--no-checkout[=<ref>]" may make the user think that this option will
>> > not checkout <ref>, and then it leads to the confusing question "but why
>> > would it checkout this f&#@ing ref in the first place?".
>> 
>> Good suggestions.
>> 
>> So, to confirm that I understand:
>> 
>>     use --no-checkout to control (no-)checkout behaviour and
>> --update-ref to specify a ref other than HEAD?
>
> Yeah, I think it would be less confusing like this.

When used without "--no-checkout" option, "bisect" need to check-out the candidate version. What good would it do if it does _not_ update HEAD when it does so?

While you are correct to point out --[no-]checkout is a boolean option, this "we do not update HEAD but update this other thing" is not orthogonal to the option. It does not make sense when we actually touch the working tree.

My preference is not to play games with "we can specify a ref other than HEAD" until somebody can demonstrate why it is a feature "because we need to be able to do so in such and such times", not merely "because we can".