On Wed, Aug 3, 2011 at 4:00 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Jon Seymour <jon.seymour@xxxxxxxxx> 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,
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html