Alban Gruin <alban.gruin@xxxxxxxxx> 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.
