Jens Lehmann <Jens.Lehmann@xxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html