Re: [PATCH v2] parse-options: don't emit "ambiguous option" for aliases

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 18, 2019, 00:48 UTC
Message-ID: <xmqq4l6wjfyw.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CACsJy8D215hMvfCwz1G9mP2te-ZERVaMMRrnM=MK1_bc0oFsjw@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 8 quoted lines

>>         { OPTION_CALLBACK, 0, "recursive", &option_recurse_submodules,
>>           N_("pathspec"), N_("initialize submodules in the clone"),
>> -         PARSE_OPT_OPTARG | PARSE_OPT_HIDDEN, recurse_submodules_cb,
>> -         (intptr_t)"." },
>> +         PARSE_OPT_OPTARG | PARSE_OPT_HIDDEN | PARSE_OPT_NOCOMPLETE,
>
> What happens if someone adds --recursive-hard? --recursi then
> resolving to --recursive-hard sounds wrong.

That was exactly my initial reaction. Or "recurse-submodules" gets renamed away, and "recommend" gets added---now "--rec" is still not ambiguous as "recursive" is marked not to participate in the disambiguation (I think OPT_NOCOMPLETE should at least be renamed to OPT_NO_DISAMBIGUATION or something---if we were to use it for the purpose of marking an option as "not participating in disambiguation", but I am fairly negative on the approach).

And my initial reaction was followed by "don't we want a more explicit link only between recursive and recurse-submodules?", which exactly matches what you said below ;-)

> But on the other hand I can see it's a bit more work to teach
> parse-options OPT_ALIAS to say "--recursive is just an alias of
> --recurse-submodules" and chances of --recursive-hard coming up are
> probably very low.

The "bit more work" is something that is worth doing in this case, I think.

Thanks.