From: Junio C Hamano Date: Wed, 03 Nov 2010 22:36:07 GMT Subject: Re: [RFC PATCH] clone: Deprecate the --recursive option in favor of --recurse-submodules Message-ID: <7vbp66vxuw.fsf@alter.siamese.dyndns.org> In-Reply-To: <4CD1ACF7.6040108@web.de> Jens Lehmann writes: > ... For my first recursion patches a > few months ago I started with --recurse-submodules but then I noticed > that "git clone" already used "--recursive" for the same purpose, and > for consistency reasons I switched to using that too. But especially > when looking at recursive grep it is really easy to misinterpret > --recursive, so the idea came up to use --recurse-submodules everywhere. > > Opinions? I think it would make sense to _add_ --recurse-submodules to "clone" to make everybody consistent. With the introduction of --recurse-submodules option, the user can rest assured that --recurse-submodules is understood by any command that knows how to descend into submodules. A command may have --recursive option (or it may not), and when it does, the option may or may not mean descending into submodules. E.g. if "git ls-tree" learns long options, --recursive would mean "recurse into subtrees" and you would say --no-recursive to countermand. As it does not make any sense to say "clone --no-recursive" to limit the clone to the top-level directory, --recursive to "clone" would need to mean "descend into subprojects". So in that sense, "clone --recursive" shares a similar degree of obviousness with "submodule --recursive". I thing it is too strong to _deprecate_ the option in the context of that command.