Re: [RFC PATCH] clone: Deprecate the --recursive option in favor of --recurse-submodules

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 3, 2010, 22:36 UTC
Message-ID: <7vbp66vxuw.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4CD1ACF7.6040108@web.de>

Jens Lehmann <Jens.Lehmann@web.de> writes:

Show 8 quoted lines

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