From: Jon Seymour <jon.seymour@gmail.com>
Date: Tue, 02 Aug 2011 21:24:27 GMT
Subject: Re: [PATCH v13 4/8] bisect: introduce support for --no-checkout option.
Message-ID: <CAH3Anrrf5aZMEH8KmKtvdaRf=D9fb6OVRJN+VjGM8Cd2wV6rnA@mail.gmail.com>
In-Reply-To: <7vr553elsd.fsf@alter.siamese.dyndns.org>

On Wed, Aug 3, 2011 at 4:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jon Seymour <jon.seymour@gmail.com> writes:
>
>> If --no-checkout is specified, then the bisection process uses:
>>
>>       git update-ref --no-deref HEAD <trial>
>>
>> at each trial instead of:
>>
>>       git checkout <trial>
>> ...
>
> Ok.
>
>>  int cmd_bisect__helper(int argc, const char **argv, const char *prefix)
>>  {
>>       int next_all = 0;
>> +     int no_checkout = 0;
>> +     char *bisect_mode=NULL;
>>       struct option options[] = {
>>               OPT_BOOLEAN(0, "next-all", &next_all,
>>                           "perform 'git bisect next'"),
>> +             OPT_STRING(0, "bisect-mode", &bisect_mode, "mode",
>> +                         "the bisection mode either checkout or update-ref. defaults to checkout."),
>
> I think this is a regression from naming perspective from the previous
> round. You would be either the normal (checkout) mode or no-checkout mode,
> and honestly, --no-checkout would be understood by anybody while update-ref
> would be understood only by Gitz.
>

Is it relevant here that --bisect-mode here is on bisect--helper which
is really part of the plumbing and unlikely to be used by anything
other than git's own porcelain?

I did leave the porcelain option as --no-checkout.

I personally think the git-bisect.sh implementation which uses
BISECT_MODE internally is slightly simpler than the one that uses
BISECT_NO_CHECKOUT.

Are you ok if I keep roughly the v13 git-bisect.sh implementation, but
revert the bisect--helper.c to v11 (adjusting git-bisect.sh to
compensate)?

jon,