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

[Junio C Hamano <gitster@pobox.com>]

Alban Gruin <alban.gruin@gmail.com> writes:

> Junio did mention[0] that --recursive was no longer in the manual, but
> not that it was once hidden from the option list.

Please allow me to summarize the discussion so far.

We want our subcommands to take "--recurse-submodules=<arg>"
uniformly, while accepting any unique prefix, e.g. --recurs=<arg>,
as its short-hand.

For "git clone", we kept "--recurse=<it>" in the options[] table as
a HIDDEN entry as part of our deprecation plan.  This nicely hid the
deprecated "--recurse=<it>" from "git clone -h".

But it backfired because "git cmd --recur=<it>" was not a "unique
prefix" (as it matched both) and triggered a disambiguation error.
To solve it, we introduced OPT_ALIAS() to tell the machinery that
allows unique prefix that these two are the same thing.  As a side
effect, because the use of OPT_ALIAS() did not have HIDDEN bit, we
started showing the deprecated "--recurse" in "git clone -h" output.

Is that where we are?

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).

or

 * adding the PARSE_OPT_HIDDEN bit to the OPT_ALIAS() element for
   the deprecated "recurse" option.

and all would be fine?

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.

Thanks.