Re: [PATCH v1] git-clone.txt: add the --recursive option

From: Junio C Hamano <gitster@pobox.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Alban Gruin <alban.gruin@gmail.com>, Git List <git@vger.kernel.org>
Subject: Re: [PATCH v1] git-clone.txt: add the --recursive option
Date: Tue, 14 Sep 2021 11:31:46 -0700	[thread overview]
Message-ID: <xmqqtuin1019.fsf@gitster.g> (raw)
In-Reply-To: <CAPig+cTQNkwWgpgu-Mw=Qd++cUVnFrrdnaQnaSZ79RexnNQFHg@mail.gmail.com> (Eric Sunshine's message of "Tue, 14 Sep 2021 13:53:11 -0400")

Eric Sunshine <sunshine@sunshineco.com> writes:

> On Tue, Sep 14, 2021 at 1:46 PM Junio C Hamano <gitster@pobox.com> wrote:
>> I am wondering if it is just a matter of either
>>
>>  * removing the "recursive" alias from the options table.  Because
>>    we accept unique prefix, --recurse=<arg> the user types will be
>>    taken as --recurse-submodules=<arg> anyway (until "git clone"
>>    learns another option --recurse-xyzzy=<arg>, at which time it
>>    will become ambiguous and error out, that is).
>
> With this option, we risk breaking existing tooling which happens to
> use the deprecated --recursive.

Ahh, sorry and thanks for correcting my stupid thinko.  recursive is
not a prefix of recurse-submodules.

>>  * adding the PARSE_OPT_HIDDEN bit to the OPT_ALIAS() element for
>>    the deprecated "recurse" option.
>
> I was going to suggest this as a possible way forward to address
> Alban's most recent response to my response. The lack of
> PARSE_OPT_HIDDEN on OPT_ALIAS() almost seems like an oversight.

You may have an alias with no intention to deprecate either, so it
would make it cumbersome if OPT_ALIAS() always meant HIDDEN, just
like it currently is cumbersome for an alias that is deprecated.

Independently (because I do not think this helps in solving the
current situation), we might want to tweak the disambiguation
machinery to require HIDDEN ones to be spelled out exactly, because
they are hidden for a reason---we do not want users to casually and
accidentally trigger them.  Of course, that is totally outside the
scope of everything we discussed so far.

>> Between adding "--recursive" to the manual and describing it as a
>> deprecated synonym for "--recurse-submodules", and not doing so, I
>> do not have a strong preference.
>
> I don't have a strong preference either, especially considering how
> long ago --recursive was removed from the manual, however, adding it
> would help someone who runs across --recursive in existing tooling or
> old blog post and wants to know what it does.

Makes sense.  I think we list other deprecated ones for that exact
reason.