{"thread":{"id":"25630","subject":"[RFC PATCH] clone: Deprecate the --recursive option in favor of --recurse-submodules","startedAt":"2010-11-03T18:41:59Z","lastAt":"2010-11-04T20:27:12Z","messageCount":5,"participants":["Jens Lehmann","Jakub Narebski","Sverre Rabbelier","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"155080","messageId":"4CD1ACF7.6040108@web.de","threadId":"25630","inReplyTo":null,"subject":"[RFC PATCH] clone: Deprecate the --recursive option in favor of --recurse-submodules","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2010-11-03T18:41:59Z","receivedAt":"2010-11-03T18:41:59Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Since 1.6.5 \"git clone\" honors the --recursive option to recursively check\nout submodules too. As this option can easily be misinterpreted when it is\nadded to other commands like \"git grep\", add the new --recurse-submodules\noption to avoid confusing it with other types of recursion.\n\nSigned-off-by: Jens Lehmann <Jens.Lehmann@web.de>\n---\n\n\nAt the GitTogether some of us were talking about a sane option name for\nrecursing submodules which should then be used consistently by all\ncommands (maybe with the exception of \"git submodule\", as --recursive\nthere has a pretty obvious meaning). For my first recursion patches a\nfew months ago I started with --recurse-submodules but then I noticed\nthat \"git clone\" already used \"--recursive\" for the same purpose, and\nfor consistency reasons I switched to using that too. But especially\nwhen looking at recursive grep it is really easy to misinterpret\n--recursive, so the idea came up to use --recurse-submodules everywhere.\n\nOpinions?\n\n\n Documentation/git-clone.txt |    5 +++--\n builtin/clone.c             |   10 ++++++++--\n 2 files changed, 11 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\nindex ab72933..1768cef 100644\n--- a/Documentation/git-clone.txt\n+++ b/Documentation/git-clone.txt\n@@ -12,7 +12,7 @@ SYNOPSIS\n 'git clone' [--template=<template_directory>]\n \t  [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]\n \t  [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>]\n-\t  [--depth <depth>] [--recursive] [--] <repository> [<directory>]\n+\t  [--depth <depth>] [--recurse-submodules] [--] <repository> [<directory>]\n\n DESCRIPTION\n -----------\n@@ -166,13 +166,14 @@ objects from the source repository into a pack in the cloned repository.\n \twith a long history, and would want to send in fixes\n \tas patches.\n\n---recursive::\n+--recurse-submodules::\n \tAfter the clone is created, initialize all submodules within,\n \tusing their default settings. This is equivalent to running\n \t`git submodule update --init --recursive` immediately after\n \tthe clone is finished. This option is ignored if the cloned\n \trepository does not have a worktree/checkout (i.e. if any of\n \t`--no-checkout`/`-n`, `--bare`, or `--mirror` is given)\n+\tThis option replaces the now deprecated `--recursive`.\n\n <repository>::\n \tThe (possibly remote) repository to clone from.  See the\ndiff --git a/builtin/clone.c b/builtin/clone.c\nindex 19ed640..91e7fab 100644\n--- a/builtin/clone.c\n+++ b/builtin/clone.c\n@@ -43,7 +43,7 @@ static char *option_template, *option_reference, *option_depth;\n static char *option_origin = NULL;\n static char *option_branch = NULL;\n static char *option_upload_pack = \"git-upload-pack\";\n-static int option_verbosity;\n+static int option_verbosity, option_recurse_submodules;\n static int option_progress;\n\n static struct option builtin_clone_options[] = {\n@@ -65,6 +65,8 @@ static struct option builtin_clone_options[] = {\n \tOPT_BOOLEAN('s', \"shared\", &option_shared,\n \t\t    \"setup as shared repository\"),\n \tOPT_BOOLEAN(0, \"recursive\", &option_recursive,\n+\t\t    \"initialize submodules in the clone (deprecated)\"),\n+\tOPT_BOOLEAN(0, \"recurse_submodules\", &option_recurse_submodules,\n \t\t    \"initialize submodules in the clone\"),\n \tOPT_STRING(0, \"template\", &option_template, \"path\",\n \t\t   \"path the template repository\"),\n@@ -659,7 +661,11 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n \t\t\t\tsha1_to_hex(our_head_points_at->old_sha1), \"1\",\n \t\t\t\tNULL);\n\n-\t\tif (!err && option_recursive)\n+\t\tif (option_recursive) {\n+\t\t\twarning(\"--recursive is deprecated; use --recurse-submodules instead.\");\n+\t\t\toption_recurse_submodules = 1;\n+\t\t}\n+\t\tif (!err && option_recurse_submodules)\n \t\t\terr = run_command_v_opt(argv_submodule, RUN_GIT_CMD);\n \t}\n\n-- \n1.7.3.2.213.g5fe186\n"},{"id":"155089","messageId":"m3aalqgion.fsf@localhost.localdomain","threadId":"25630","inReplyTo":"4CD1ACF7.6040108@web.de","subject":"Re: [RFC PATCH] clone: Deprecate the --recursive option in favor of --recurse-submodules","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-11-03T22:13:47Z","receivedAt":"2010-11-03T22:13:47Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jens Lehmann <Jens.Lehmann@web.de> writes:\n\n> @@ -65,6 +65,8 @@ static struct option builtin_clone_options[] = {\n>  \tOPT_BOOLEAN('s', \"shared\", &option_shared,\n>  \t\t    \"setup as shared repository\"),\n>  \tOPT_BOOLEAN(0, \"recursive\", &option_recursive,\n> +\t\t    \"initialize submodules in the clone (deprecated)\"),\n> +\tOPT_BOOLEAN(0, \"recurse_submodules\", &option_recurse_submodules,\n>  \t\t    \"initialize submodules in the clone\"),\n>  \tOPT_STRING(0, \"template\", &option_template, \"path\",\n>  \t\t   \"path the template repository\"),\n\nShouldn't we use PARSE_OPT_HIDDEN?  Or should it be left for later?\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"155091","messageId":"AANLkTinLQdpPC-TYjd_8CAnbPjZFGmnvJ_8X5x-yuuwP@mail.gmail.com","threadId":"25630","inReplyTo":"m3aalqgion.fsf@localhost.localdomain","subject":"Re: [RFC PATCH] clone: Deprecate the --recursive option in favor of --recurse-submodules","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-11-03T22:24:30Z","receivedAt":"2010-11-03T22:24:30Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, Nov 3, 2010 at 23:13, Jakub Narebski <jnareb@gmail.com> wrote:\n> Shouldn't we use PARSE_OPT_HIDDEN?  Or should it be left for later?\n\nI assumed we would add PARSE_OPT_HIDDEN in a few releases. Perhaps\nthat patch should also be sent.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"155092","messageId":"7vbp66vxuw.fsf@alter.siamese.dyndns.org","threadId":"25630","inReplyTo":"4CD1ACF7.6040108@web.de","subject":"Re: [RFC PATCH] clone: Deprecate the --recursive option in favor of --recurse-submodules","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-11-03T22:36:07Z","receivedAt":"2010-11-03T22:36:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann <Jens.Lehmann@web.de> writes:\n\n> ... For my first recursion patches a\n> few months ago I started with --recurse-submodules but then I noticed\n> that \"git clone\" already used \"--recursive\" for the same purpose, and\n> for consistency reasons I switched to using that too. But especially\n> when looking at recursive grep it is really easy to misinterpret\n> --recursive, so the idea came up to use --recurse-submodules everywhere.\n>\n> Opinions?\n\nI think it would make sense to _add_ --recurse-submodules to \"clone\" to\nmake everybody consistent.\n\nWith the introduction of --recurse-submodules option, the user can rest\nassured that --recurse-submodules is understood by any command that knows\nhow to descend into submodules.  A command may have --recursive option (or\nit may not), and when it does, the option may or may not mean descending\ninto submodules.  E.g. if \"git ls-tree\" learns long options, --recursive\nwould mean \"recurse into subtrees\" and you would say --no-recursive to\ncountermand.\n\nAs it does not make any sense to say \"clone --no-recursive\" to limit the\nclone to the top-level directory, --recursive to \"clone\" would need to\nmean \"descend into subprojects\".  So in that sense, \"clone --recursive\"\nshares a similar degree of obviousness with \"submodule --recursive\".  I\nthing it is too strong to _deprecate_ the option in the context of that\ncommand.\n"},{"id":"155199","messageId":"4CD31720.7080104@web.de","threadId":"25630","inReplyTo":"7vbp66vxuw.fsf@alter.siamese.dyndns.org","subject":"[PATCH] clone: Add the --recurse-submodules option as alias for --recursive","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2010-11-04T20:27:12Z","receivedAt":"2010-11-04T20:27:12Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Since 1.6.5 \"git clone\" honors the --recursive option to recursively check\nout submodules too. As this option can easily be misinterpreted when it is\nadded to other commands like \"git grep\", add the new --recurse-submodules\noption as an alias for --recursive so the same option can be used for all\ncommands recursing into submodules.\n\nSigned-off-by: Jens Lehmann <Jens.Lehmann@web.de>\n---\n\nAm 03.11.2010 23:36, schrieb Junio C Hamano:\n> Jens Lehmann <Jens.Lehmann@web.de> writes:\n> \n>> ... For my first recursion patches a\n>> few months ago I started with --recurse-submodules but then I noticed\n>> that \"git clone\" already used \"--recursive\" for the same purpose, and\n>> for consistency reasons I switched to using that too. But especially\n>> when looking at recursive grep it is really easy to misinterpret\n>> --recursive, so the idea came up to use --recurse-submodules everywhere.\n>>\n>> Opinions?\n> \n> I think it would make sense to _add_ --recurse-submodules to \"clone\" to\n> make everybody consistent.\n> ... I\n> thing it is too strong to _deprecate_ the option in the context of that\n> command.\n\nFine by me, then what about this patch?\n\nAnd am I right to assume that there are no objections against using\n--recurse-submodule for fetch, checkout & friends?\n\n\n Documentation/git-clone.txt |    4 +++-\n builtin/clone.c             |    2 ++\n 2 files changed, 5 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\nindex ab72933..d69984b 100644\n--- a/Documentation/git-clone.txt\n+++ b/Documentation/git-clone.txt\n@@ -12,7 +12,8 @@ SYNOPSIS\n 'git clone' [--template=<template_directory>]\n \t  [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]\n \t  [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>]\n-\t  [--depth <depth>] [--recursive] [--] <repository> [<directory>]\n+\t  [--depth <depth>] [--recursive|--recurse-submodules] [--] <repository>\n+\t  [<directory>]\n\n DESCRIPTION\n -----------\n@@ -167,6 +168,7 @@ objects from the source repository into a pack in the cloned repository.\n \tas patches.\n\n --recursive::\n+--recurse-submodules::\n \tAfter the clone is created, initialize all submodules within,\n \tusing their default settings. This is equivalent to running\n \t`git submodule update --init --recursive` immediately after\ndiff --git a/builtin/clone.c b/builtin/clone.c\nindex 19ed640..61e0989 100644\n--- a/builtin/clone.c\n+++ b/builtin/clone.c\n@@ -66,6 +66,8 @@ static struct option builtin_clone_options[] = {\n \t\t    \"setup as shared repository\"),\n \tOPT_BOOLEAN(0, \"recursive\", &option_recursive,\n \t\t    \"initialize submodules in the clone\"),\n+\tOPT_BOOLEAN(0, \"recurse_submodules\", &option_recursive,\n+\t\t    \"initialize submodules in the clone\"),\n \tOPT_STRING(0, \"template\", &option_template, \"path\",\n \t\t   \"path the template repository\"),\n \tOPT_STRING(0, \"reference\", &option_reference, \"repo\",\n-- \n1.7.3.2.194.ge0b67\n"}]}