{"thread":{"id":"36825","subject":"Paper cut bug: Why isn't \"git clone xxxx\" recursive by default?","startedAt":"2014-06-03T18:11:03Z","lastAt":"2017-08-02T20:35:06Z","messageCount":21,"participants":["Mara Kim","Junio C Hamano","Chris Packham","Jens Lehmann","Heiko Voigt","W. Trevor King","Jeremy Morton","Stefan Beller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"243200","messageId":"CAJdEhSa20ODuN4LkdvaWi0cSztgbJ+p50AYbtZs2oYWLitnjbA@mail.gmail.com","threadId":"36825","inReplyTo":null,"subject":"Paper cut bug: Why isn't \"git clone xxxx\" recursive by default?","fromName":"Mara Kim","fromEmail":"mara.kim@vanderbilt.edu","sentAt":"2014-06-03T18:11:03Z","receivedAt":"2014-06-03T18:11:03Z","isPatch":false,"sender":{"key":"mara.kim@vanderbilt.edu","avatar":null},"body":"Hello git devs!\n\nI'd like to start off by saying that git is an amazing piece of\nsoftware and every one of you deserve major kudos for your work on the\nproject.  However, I'd like to point out a few \"paper cut\" bugs (to\nuse the Ubuntu parlance).\n\nApologies if this question has been asked already, but what is the\nreasoning behind making git clone not recursive (--recursive) by\ndefault?  I have just recently started splitting my projects into\nsubmodules, and I feel like this is a major usability issue,\nespecially for newbies.  Wouldn't it be better to have a\n\"--non-recursive\" option and clone recursively by default?  Similarly,\nI feel that \"git pull\" should automatically \"git submodule update\n--recursive --init\" as well, with the current behavior able to be\nspecified with a \"--non-recursive\" option.\n\nI feel like these sorts of choices make submodules seem very much like\nsecond class citizens in git and make git much less user friendly.  I\nfeel that the most common use case that people want is to keep\nsubmodules properly in sync.  In addition, I feel that power users\nthat really want to make shallow clones, non-recursive clones, etc.\ncould still be served with a simple option.  I guess there are\nproblems with changes in submodules being overwritten, so I suppose\nthere would need to be additional warnings or even just refusal to\npull into dirty directories, similar to the way git behaves in a\nregular repository.\n\nThanks for the excellent work,\nMara Kim\n\nPh.D. Candidate\nComputational Biology\nVanderbilt University\nNashville, TN\n"},{"id":"243204","messageId":"xmqqvbshwz2e.fsf@gitster.dls.corp.google.com","threadId":"36825","inReplyTo":"CAJdEhSa20ODuN4LkdvaWi0cSztgbJ+p50AYbtZs2oYWLitnjbA@mail.gmail.com","subject":"Re: Paper cut bug: Why isn't \"git clone xxxx\" recursive by default?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-06-03T19:52:25Z","receivedAt":"2014-06-03T19:52:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mara Kim <mara.kim@vanderbilt.edu> writes:\n\n> Apologies if this question has been asked already, but what is the\n> reasoning behind making git clone not recursive (--recursive) by\n> default?\n\nThe primary reason why submodules are separate repositories is not\nto require people to have everything.  Some people want recursive,\nsome others don't, and the world is not always \"majority wins\" (not\nthat I am saying that majority will want recursive).\n\nInertia, aka backward compatibility and not surprising existing\nusers, plays some role when deciding the default.\n\nAlso, going --recursive when the user did not want is a lot more\nexpensive mistake to fix than not being --recursive when the user\nwanted to.\n"},{"id":"243208","messageId":"xmqqoay9wvo6.fsf@gitster.dls.corp.google.com","threadId":"36825","inReplyTo":"xmqqvbshwz2e.fsf@gitster.dls.corp.google.com","subject":"Re: Paper cut bug: Why isn't \"git clone xxxx\" recursive by default?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-06-03T21:05:45Z","receivedAt":"2014-06-03T21:05:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Mara Kim <mara.kim@vanderbilt.edu> writes:\n>\n>> Apologies if this question has been asked already, but what is the\n>> reasoning behind making git clone not recursive (--recursive) by\n>> default?\n>\n> The primary reason why submodules are separate repositories is not\n> to require people to have everything.  Some people want recursive,\n> some others don't, and the world is not always \"majority wins\" (not\n> that I am saying that majority will want recursive).\n>\n> Inertia, aka backward compatibility and not surprising existing\n> users, plays some role when deciding the default.\n>\n> Also, going --recursive when the user did not want is a lot more\n> expensive mistake to fix than not being --recursive when the user\n> wanted to.\n\nHaving said all that, I do not mean to say that I am opposed to\nintroduce some mechanism to let the users express their preference\nbetween recursive and non-recursive better, so that \"git clone\"\nwithout an explicit --recursive (or --no-recursive) can work to\ntheir taste.  A configuration in $HOME/.gitconfig might be a place\nto start, even though that has the downside of assuming that the\ngiven user would want to use the same settings for all his projects,\nwhich may not be the case in practice.\n"},{"id":"243269","messageId":"CAJdEhSbo_-s7T9Mu=sM+-60s8t28NDogoA36xJoZowwU3hErOg@mail.gmail.com","threadId":"36825","inReplyTo":"xmqqoay9wvo6.fsf@gitster.dls.corp.google.com","subject":"Re: Paper cut bug: Why isn't \"git clone xxxx\" recursive by default?","fromName":"Mara Kim","fromEmail":"mara.kim@vanderbilt.edu","sentAt":"2014-06-03T22:24:41Z","receivedAt":"2014-06-03T22:24:41Z","isPatch":false,"sender":{"key":"mara.kim@vanderbilt.edu","avatar":null},"body":"That is good to hear.  I would be pretty happy about that. ^.^\n\nObviously any major changes will need to be done carefully.  I was\nthinking of the way that you guys introduced new defaults for Git 2.0,\nphasing them in slowly through the 1.x cycle.  Maybe I can get my\nhopes up for Git 3.0 --- 9 years from now :P\n\nOn Tue, Jun 3, 2014 at 4:05 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> Mara Kim <mara.kim@vanderbilt.edu> writes:\n>>\n>>> Apologies if this question has been asked already, but what is the\n>>> reasoning behind making git clone not recursive (--recursive) by\n>>> default?\n>>\n>> The primary reason why submodules are separate repositories is not\n>> to require people to have everything.  Some people want recursive,\n>> some others don't, and the world is not always \"majority wins\" (not\n>> that I am saying that majority will want recursive).\n>>\n>> Inertia, aka backward compatibility and not surprising existing\n>> users, plays some role when deciding the default.\n>>\n>> Also, going --recursive when the user did not want is a lot more\n>> expensive mistake to fix than not being --recursive when the user\n>> wanted to.\n>\n> Having said all that, I do not mean to say that I am opposed to\n> introduce some mechanism to let the users express their preference\n> between recursive and non-recursive better, so that \"git clone\"\n> without an explicit --recursive (or --no-recursive) can work to\n> their taste.  A configuration in $HOME/.gitconfig might be a place\n> to start, even though that has the downside of assuming that the\n> given user would want to use the same settings for all his projects,\n> which may not be the case in practice.\n>\n\n\n\n-- \nMara Kim\n\nPh.D. Candidate\nComputational Biology\nVanderbilt University\nNashville, TN\n"},{"id":"243281","messageId":"1401874256-13332-1-git-send-email-judge.packham@gmail.com","threadId":"36825","inReplyTo":"xmqqoay9wvo6.fsf@gitster.dls.corp.google.com","subject":"[RFC PATCH] clone: add clone.recursesubmodules config option","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2014-06-04T09:30:56Z","receivedAt":"2014-06-04T09:30:56Z","isPatch":true,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Add a config option that will cause clone to recurse into submodules as\nif the --recurse-submodules option had been specified on the command\nline. This can be overridden with the --no-recurse-submodules option.\n\nSigned-off-by: Chris Packham <judge.packham@gmail.com>\n---\nOn 04/06/14 09:05, Junio C Hamano wrote:\n>> Mara Kim <mara.kim@vanderbilt.edu> writes:\n>>\n>>> Apologies if this question has been asked already, but what is the\n>>> reasoning behind making git clone not recursive (--recursive) by\n>>> default?\n>>\n>> The primary reason why submodules are separate repositories is not\n>> to require people to have everything.  Some people want recursive,\n>> some others don't, and the world is not always \"majority wins\" (not\n>> that I am saying that majority will want recursive).\n>>\n>> Inertia, aka backward compatibility and not surprising existing\n>> users, plays some role when deciding the default.\n>>\n>> Also, going --recursive when the user did not want is a lot more\n>> expensive mistake to fix than not being --recursive when the user\n>> wanted to.\n> \n> Having said all that, I do not mean to say that I am opposed to\n> introduce some mechanism to let the users express their preference\n> between recursive and non-recursive better, so that \"git clone\"\n> without an explicit --recursive (or --no-recursive) can work to\n> their taste.  A configuration in $HOME/.gitconfig might be a place\n> to start, even though that has the downside of assuming that the\n> given user would want to use the same settings for all his projects,\n> which may not be the case in practice.\n\nAnd here's a quick proof of concept. Not sure about the config variable name\nand it could probably do with a negative test as well.\n\n builtin/clone.c              |  9 +++++++++\n t/t7407-submodule-foreach.sh | 17 +++++++++++++++++\n 2 files changed, 26 insertions(+)\n\ndiff --git a/builtin/clone.c b/builtin/clone.c\nindex b12989d..92aea81 100644\n--- a/builtin/clone.c\n+++ b/builtin/clone.c\n@@ -734,6 +734,14 @@ static void write_refspec_config(const char* src_ref_prefix,\n \tstrbuf_release(&value);\n }\n \n+static int git_clone_config(const char *key, const char *value, void *data)\n+{\n+\tif (!strcmp(key, \"clone.recursesubmodules\"))\n+\t\toption_recursive = git_config_bool(key, value);\n+\n+\treturn 0;\n+}\n+\n int cmd_clone(int argc, const char **argv, const char *prefix)\n {\n \tint is_bundle = 0, is_local;\n@@ -759,6 +767,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n \tjunk_pid = getpid();\n \n \tpacket_trace_identity(\"clone\");\n+\tgit_config(git_clone_config, NULL);\n \targc = parse_options(argc, argv, prefix, builtin_clone_options,\n \t\t\t     builtin_clone_usage, 0);\n \ndiff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh\nindex 7ca10b8..fc2c189 100755\n--- a/t/t7407-submodule-foreach.sh\n+++ b/t/t7407-submodule-foreach.sh\n@@ -307,6 +307,23 @@ test_expect_success 'use \"update --recursive nested1\" to checkout all submodules\n \t)\n '\n \n+test_expect_success 'use \"git clone\" with clone.recursesubmodules to checkout all submodules' '\n+\tgit config --local clone.recursesubmodules true &&\n+\tgit clone super clone7 &&\n+\t(\n+\t\tcd clone7 &&\n+\t\tgit rev-parse --resolve-git-dir .git &&\n+\t\tgit rev-parse --resolve-git-dir sub1/.git &&\n+\t\tgit rev-parse --resolve-git-dir sub2/.git &&\n+\t\tgit rev-parse --resolve-git-dir sub3/.git &&\n+\t\tgit rev-parse --resolve-git-dir nested1/.git &&\n+\t\tgit rev-parse --resolve-git-dir nested1/nested2/.git &&\n+\t\tgit rev-parse --resolve-git-dir nested1/nested2/nested3/.git &&\n+\t\tgit rev-parse --resolve-git-dir nested1/nested2/nested3/submodule/.git\n+\t) &&\n+\tgit config --local --unset clone.recursesubmodules\n+'\n+\n test_expect_success 'command passed to foreach retains notion of stdin' '\n \t(\n \t\tcd super &&\n-- \n2.0.0.153.g79dcccc\n"},{"id":"243308","messageId":"xmqqvbsgvb9l.fsf@gitster.dls.corp.google.com","threadId":"36825","inReplyTo":"1401874256-13332-1-git-send-email-judge.packham@gmail.com","subject":"Re: [RFC PATCH] clone: add clone.recursesubmodules config option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-06-04T17:24:06Z","receivedAt":"2014-06-04T17:24:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chris Packham <judge.packham@gmail.com> writes:\n\n> On 04/06/14 09:05, Junio C Hamano wrote:\n>>> Also, going --recursive when the user did not want is a lot more\n>>> expensive mistake to fix than not being --recursive when the user\n>>> wanted to.\n>> \n>> Having said all that, I do not mean to say that I am opposed to\n>> introduce some mechanism to let the users express their preference\n>> between recursive and non-recursive better, so that \"git clone\"\n>> without an explicit --recursive (or --no-recursive) can work to\n>> their taste.  A configuration in $HOME/.gitconfig might be a place\n>> to start, even though that has the downside of assuming that the\n>> given user would want to use the same settings for all his projects,\n>> which may not be the case in practice.\n>\n> And here's a quick proof of concept. Not sure about the config variable name\n> and it could probably do with a negative test as well.\n\nI would be more worried about the semantics than the name, though;\nre-read the part you quoted with extra stress on \"has the downside\".\n\nI think I heard the submodule folks (cc'ed) discuss an approach to\nallow various submodules to be marked with \"tags\" with a new type of\nentry in .gitmodules file in the superproject, and use these tags to\nsignal \"by default, a new clone will recurse into this submodule\".\n\nE.g. if projects standardized on \"defaultClone\" to mark such\nsubmodules, then $HOME/.gitconfig could say\n\n    [clone]\n        recursesubmodules = defaultClone\n\nOr the projects may mark platform specific submodules with tags,\ne.g. a .gitmodules in a typical superproject might say something\nlike this:\n\n    [submodule \"posix\"]\n    \tpath = ports/posix\n        tags = linux obsd fbsd osx\n    [submodule \"windows\"]\n        path = ports/windows\n        tags = win32\n    [submodule \"doc\"]\n    \tpath = documentation\n        tags = defaultClone\n\nand then the user's $HOME/.gitconfig might say\n\n    [clone]\n        recursesubmodules = defaultClone win32\n\nto tell a \"git clone\" of such a superproject to clone the top-level,\nread its .gitmodules, and choose documentation/ and ports/windows\nsubmodules but not ports/posix submodule to be further cloned into\nthe working tree of the superproject.\n\nOf course, if this kind of project organization proves to be useful,\nwe should try to standardize the set of tags early before people\nstart coming up with random variations of the same thing, spelling\nthe same concept in different ways only to be different, and if that\nhappens, then we could even give a non-empty default value for the\nclone.recursesubmodules when $HOME/.gitconfig is missing one.\n\nJust a random thought.\n"},{"id":"243333","messageId":"538F6E52.9000009@web.de","threadId":"36825","inReplyTo":"xmqqvbsgvb9l.fsf@gitster.dls.corp.google.com","subject":"Re: [RFC PATCH] clone: add clone.recursesubmodules config option","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2014-06-04T19:06:58Z","receivedAt":"2014-06-04T19:06:58Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 04.06.2014 19:24, schrieb Junio C Hamano:\n> Chris Packham <judge.packham@gmail.com> writes:\n> \n>> On 04/06/14 09:05, Junio C Hamano wrote:\n>>>> Also, going --recursive when the user did not want is a lot more\n>>>> expensive mistake to fix than not being --recursive when the user\n>>>> wanted to.\n>>>\n>>> Having said all that, I do not mean to say that I am opposed to\n>>> introduce some mechanism to let the users express their preference\n>>> between recursive and non-recursive better, so that \"git clone\"\n>>> without an explicit --recursive (or --no-recursive) can work to\n>>> their taste.  A configuration in $HOME/.gitconfig might be a place\n>>> to start, even though that has the downside of assuming that the\n>>> given user would want to use the same settings for all his projects,\n>>> which may not be the case in practice.\n>>\n>> And here's a quick proof of concept. Not sure about the config variable name\n>> and it could probably do with a negative test as well.\n> \n> I would be more worried about the semantics than the name, though;\n> re-read the part you quoted with extra stress on \"has the downside\".\n> \n> I think I heard the submodule folks (cc'ed) discuss an approach to\n> allow various submodules to be marked with \"tags\" with a new type of\n> entry in .gitmodules file in the superproject, and use these tags to\n> signal \"by default, a new clone will recurse into this submodule\".\n> \n> E.g. if projects standardized on \"defaultClone\" to mark such\n> submodules, then $HOME/.gitconfig could say\n> \n>     [clone]\n>         recursesubmodules = defaultClone\n> \n> Or the projects may mark platform specific submodules with tags,\n> e.g. a .gitmodules in a typical superproject might say something\n> like this:\n> \n>     [submodule \"posix\"]\n>     \tpath = ports/posix\n>         tags = linux obsd fbsd osx\n>     [submodule \"windows\"]\n>         path = ports/windows\n>         tags = win32\n>     [submodule \"doc\"]\n>     \tpath = documentation\n>         tags = defaultClone\n> \n> and then the user's $HOME/.gitconfig might say\n> \n>     [clone]\n>         recursesubmodules = defaultClone win32\n> \n> to tell a \"git clone\" of such a superproject to clone the top-level,\n> read its .gitmodules, and choose documentation/ and ports/windows\n> submodules but not ports/posix submodule to be further cloned into\n> the working tree of the superproject.\n> \n> Of course, if this kind of project organization proves to be useful,\n> we should try to standardize the set of tags early before people\n> start coming up with random variations of the same thing, spelling\n> the same concept in different ways only to be different, and if that\n> happens, then we could even give a non-empty default value for the\n> clone.recursesubmodules when $HOME/.gitconfig is missing one.\n\nYes, but maybe we can define how the user wants to set the global or\nper-repo default (that is honored as long as upstream or local\nconfig doesn't provide more specific settings, e.g. via tags) and\nimplement that for clone as a first step, even when we do not now\nhow e.g. the tags setting might look like in the end. I believe we\nshould have one or two switches telling Git \"I want my submodules be\nupdated without having to use the 'git submodule' command\". And\nafter that submodule specific overrides can kick in, e.g. when\n\"submodule.<name>.update\" is set to \"none\" the submodule won't be\nupdated no matter how the default is.\n\nWe had two settings in mind, first \"submodule.autoinit\" (which would\nautomate the \"git submodule --init\" step and also control that a\nnew submodule is fetched into .git/modules; it'd be fetched there\nsoon as the fetch in the superproject sees a commit introducing it).\nThat would kick in on clone, fetch and pull, as the underlying fetch\nhonors it. And the \"submodule.autoupdate\" setting which will make\nrunning \"git submodule update\" obsolete by updating all init'ed\nsubmodules on each clone, checkout, merge, reset etc.. Together\nthey'd achieve for all relevant commands what Chris' proposed option\nwould only do for clone.\n\nSo what if clone would just do an \"git submodule init\" for now when\n\"submodule.autoinit\" is set but \"submodule.autoupdate\" isn't (and as\nsoon as fetch learns to honor autoinit we could remove that one\nagain). And if both are set it'd do a \"git submodule update --init\n--recursive\", just like it does when the --recurse-submodules option\nis used. As soon as we also have recursive submodule update, we could\nremove the latter from clone.\n\nBut maybe we are to close to the implementation side of things (where\nfetch and checkout just like init and update are two separate things)\nand a single \"submodule.auto\" setting would be what users really want?\n\nComments welcome.\n"},{"id":"243336","messageId":"20140604194216.GA4636@sandbox-ub","threadId":"36825","inReplyTo":"xmqqvbsgvb9l.fsf@gitster.dls.corp.google.com","subject":"Re: Re: [RFC PATCH] clone: add clone.recursesubmodules config option","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2014-06-04T19:42:16Z","receivedAt":"2014-06-04T19:42:16Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Wed, Jun 04, 2014 at 10:24:06AM -0700, Junio C Hamano wrote:\n> Chris Packham <judge.packham@gmail.com> writes:\n> \n> > On 04/06/14 09:05, Junio C Hamano wrote:\n> >>> Also, going --recursive when the user did not want is a lot more\n> >>> expensive mistake to fix than not being --recursive when the user\n> >>> wanted to.\n> >> \n> >> Having said all that, I do not mean to say that I am opposed to\n> >> introduce some mechanism to let the users express their preference\n> >> between recursive and non-recursive better, so that \"git clone\"\n> >> without an explicit --recursive (or --no-recursive) can work to\n> >> their taste.  A configuration in $HOME/.gitconfig might be a place\n> >> to start, even though that has the downside of assuming that the\n> >> given user would want to use the same settings for all his projects,\n> >> which may not be the case in practice.\n> >\n> > And here's a quick proof of concept. Not sure about the config variable name\n> > and it could probably do with a negative test as well.\n> \n> I would be more worried about the semantics than the name, though;\n> re-read the part you quoted with extra stress on \"has the downside\".\n> \n> I think I heard the submodule folks (cc'ed) discuss an approach to\n> allow various submodules to be marked with \"tags\" with a new type of\n> entry in .gitmodules file in the superproject, and use these tags to\n> signal \"by default, a new clone will recurse into this submodule\".\n> \n> E.g. if projects standardized on \"defaultClone\" to mark such\n> submodules, then $HOME/.gitconfig could say\n> \n>     [clone]\n>         recursesubmodules = defaultClone\n> \n> Or the projects may mark platform specific submodules with tags,\n> e.g. a .gitmodules in a typical superproject might say something\n> like this:\n> \n>     [submodule \"posix\"]\n>     \tpath = ports/posix\n>         tags = linux obsd fbsd osx\n>     [submodule \"windows\"]\n>         path = ports/windows\n>         tags = win32\n>     [submodule \"doc\"]\n>     \tpath = documentation\n>         tags = defaultClone\n> \n> and then the user's $HOME/.gitconfig might say\n> \n>     [clone]\n>         recursesubmodules = defaultClone win32\n> \n> to tell a \"git clone\" of such a superproject to clone the top-level,\n> read its .gitmodules, and choose documentation/ and ports/windows\n> submodules but not ports/posix submodule to be further cloned into\n> the working tree of the superproject.\n> \n> Of course, if this kind of project organization proves to be useful,\n> we should try to standardize the set of tags early before people\n> start coming up with random variations of the same thing, spelling\n> the same concept in different ways only to be different, and if that\n> happens, then we could even give a non-empty default value for the\n> clone.recursesubmodules when $HOME/.gitconfig is missing one.\n> \n> Just a random thought.\n\nI like this idea of specifying different \"views\" by giving tags. But\ndoes it rule out a boolean clone.recursesubmodules? For the simple case\nsome people might not want to worry about specifying tags but just want\nto configure: \"Yes give me everything\". So if we were to do this I would\nlike it if we could have both. Also because the option for clone is\n--recurse-submodules and our typical schema is that a configuration\noption is named similar so clone.recursesubmodules would fit here.\n\nSo either we do this \"magically\" and all valid boolean values are\nforbidden as tags or we would need a different config option. Further\nthinking about it: Maybe a general option that does not only apply to\nclone would suit the \"views\" use-case more. E.g. \"submodule.tags\" or\nsimilar.\n\nAlso please note: We have been talking about adding two configurations\nfor submodules:\n\n\tsubmodule.\"name\".autoclone (IIRC)\n\nI am not sure whether that was the correct name, but this option should\ntell recursive fetch / clone whether to automatically clone a submodule\nwhen it appears on a fetch in the history.\n\n\tsubmodule.\"name\".autoinit\n\nAnd this one is for recursive checkout and tells whether an appearing\nsubmodule should automatically be initialized.\n\nThese options fullfill a similar use-case and are planned for the future\nwhen recursive fetch/clone and checkout are in place (which is not that\nfar away). We might need to rethink these to incoporate the \"views from\ntags\" idea nicely and since we do not want a configuration nightmare.\n\nCheers Heiko\n"},{"id":"243379","messageId":"539020D1.1090601@gmail.com","threadId":"36825","inReplyTo":"20140604194216.GA4636@sandbox-ub","subject":"Re: [RFC PATCH] clone: add clone.recursesubmodules config option","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2014-06-05T07:48:33Z","receivedAt":"2014-06-05T07:48:33Z","isPatch":true,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On 05/06/14 07:42, Heiko Voigt wrote:\n> On Wed, Jun 04, 2014 at 10:24:06AM -0700, Junio C Hamano wrote:\n>> Chris Packham <judge.packham@gmail.com> writes:\n>>\n>>> On 04/06/14 09:05, Junio C Hamano wrote:\n>>>>> Also, going --recursive when the user did not want is a lot more\n>>>>> expensive mistake to fix than not being --recursive when the user\n>>>>> wanted to.\n>>>>\n>>>> Having said all that, I do not mean to say that I am opposed to\n>>>> introduce some mechanism to let the users express their preference\n>>>> between recursive and non-recursive better, so that \"git clone\"\n>>>> without an explicit --recursive (or --no-recursive) can work to\n>>>> their taste.  A configuration in $HOME/.gitconfig might be a place\n>>>> to start, even though that has the downside of assuming that the\n>>>> given user would want to use the same settings for all his projects,\n>>>> which may not be the case in practice.\n>>>\n>>> And here's a quick proof of concept. Not sure about the config variable name\n>>> and it could probably do with a negative test as well.\n>>\n>> I would be more worried about the semantics than the name, though;\n>> re-read the part you quoted with extra stress on \"has the downside\".\n>>\n>> I think I heard the submodule folks (cc'ed) discuss an approach to\n>> allow various submodules to be marked with \"tags\" with a new type of\n>> entry in .gitmodules file in the superproject, and use these tags to\n>> signal \"by default, a new clone will recurse into this submodule\".\n>>\n>> E.g. if projects standardized on \"defaultClone\" to mark such\n>> submodules, then $HOME/.gitconfig could say\n>>\n>>     [clone]\n>>         recursesubmodules = defaultClone\n>>\n>> Or the projects may mark platform specific submodules with tags,\n>> e.g. a .gitmodules in a typical superproject might say something\n>> like this:\n>>\n>>     [submodule \"posix\"]\n>>     \tpath = ports/posix\n>>         tags = linux obsd fbsd osx\n>>     [submodule \"windows\"]\n>>         path = ports/windows\n>>         tags = win32\n>>     [submodule \"doc\"]\n>>     \tpath = documentation\n>>         tags = defaultClone\n>>\n>> and then the user's $HOME/.gitconfig might say\n>>\n>>     [clone]\n>>         recursesubmodules = defaultClone win32\n>>\n>> to tell a \"git clone\" of such a superproject to clone the top-level,\n>> read its .gitmodules, and choose documentation/ and ports/windows\n>> submodules but not ports/posix submodule to be further cloned into\n>> the working tree of the superproject.\n>>\n>> Of course, if this kind of project organization proves to be useful,\n>> we should try to standardize the set of tags early before people\n>> start coming up with random variations of the same thing, spelling\n>> the same concept in different ways only to be different, and if that\n>> happens, then we could even give a non-empty default value for the\n>> clone.recursesubmodules when $HOME/.gitconfig is missing one.\n>>\n>> Just a random thought.\n> \n> I like this idea of specifying different \"views\" by giving tags. But\n> does it rule out a boolean clone.recursesubmodules? For the simple case\n> some people might not want to worry about specifying tags but just want\n> to configure: \"Yes give me everything\". So if we were to do this I would\n> like it if we could have both. Also because the option for clone is\n> --recurse-submodules and our typical schema is that a configuration\n> option is named similar so clone.recursesubmodules would fit here.\n\nMaybe using a glob pattern would work.\n\nThe user might say\n\n     [clone]\n         recursesubmodules = x86*\n\nAnd .gitmodules might say\n\n     [submodule \"foo\"]\n         tags = x86_64\n     [submodule \"bar\"]\n         tags = x86\n     [submodule \"frotz\"]\n         tags = powerpc\n\nFor the \"Yes give me everything\" case the user could say\n\n     [clone]\n         recursesubmodules = *\n\n> \n> So either we do this \"magically\" and all valid boolean values are\n> forbidden as tags or we would need a different config option. Further\n> thinking about it: Maybe a general option that does not only apply to\n> clone would suit the \"views\" use-case more. E.g. \"submodule.tags\" or\n> similar.\n> \n> Also please note: We have been talking about adding two configurations\n> for submodules:\n> \n> \tsubmodule.\"name\".autoclone (IIRC)\n> \n> I am not sure whether that was the correct name, but this option should\n> tell recursive fetch / clone whether to automatically clone a submodule\n> when it appears on a fetch in the history.\n> \n> \tsubmodule.\"name\".autoinit\n> \n> And this one is for recursive checkout and tells whether an appearing\n> submodule should automatically be initialized.\n> \n> These options fullfill a similar use-case and are planned for the future\n> when recursive fetch/clone and checkout are in place (which is not that\n> far away). We might need to rethink these to incoporate the \"views from\n> tags\" idea nicely and since we do not want a configuration nightmare.\n> \n> Cheers Heiko\n> \n\nI'm a little confused at how autoclone and autoinit differ. Aren't they\nthe same? i.e. when this module appears grab it by default. I see\nautoupdate as a little different meaning update it if it's been\ninitialised. Also does autoinit imply autoupdate?\n\nAt $dayjob we have a superproject which devs clone this has submodules\nfor the important and/or high touch repositories. We have other\nrepositories that are normally build from a tarball (or not built at\nall) but we can build them from external repositories if needed. The\nlatter case is painfully manual. If autoinit/autoupdate existed we'd\nprobably setup out projects with.\n\n    [submodule \"linux\"]\n        autoinit = true\n\tautoupdate = true\n    [submodule \"userland\"]\n        autoinit = true\n\tautoupdate = true\n    [submodule \"not-used-that-much\"]\n\tautoupdate = true\n\nWe probably wouldn't make use of tags because we're building complete\nembedded systems and generally want everything, even if we are doing\nmost of our work on a particular target we need to do builds for other\ntargets for sanity checks.\n"},{"id":"243409","messageId":"xmqq4mzzte2z.fsf@gitster.dls.corp.google.com","threadId":"36825","inReplyTo":"538F6E52.9000009@web.de","subject":"Re: [RFC PATCH] clone: add clone.recursesubmodules config option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-06-05T18:18:28Z","receivedAt":"2014-06-05T18:18:28Z","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> ... I believe we\n> should have one or two switches telling Git \"I want my submodules be\n> updated without having to use the 'git submodule' command\". And\n> after that submodule specific overrides can kick in, e.g. when\n> \"submodule.<name>.update\" is set to \"none\" the submodule won't be\n> updated no matter how the default is.\n\nOK, so submodule.*.update for each submodule, and a default value\nfor submodules that do not have submodule.*.update set to anything.\n\nSounds workable.\n\n> We had two settings in mind,...\n> So what if clone would just do an \"git submodule init\" for now when\n> \"submodule.autoinit\" is set but \"submodule.autoupdate\" isn't [?]\n> ... and a single \"submodule.auto\" setting would be what users really want?\n\nI do not offhand think of a sensible scenario where you want to init\na submodule once but do not want to update it when the superproject\nchanges.  Even if the user uses the mode to detach the submodule\nHEAD, i.e. the branches in submodules do not matter and the whole\ntree is described by the superproject's commit and gitlinks recorded\nin it, the user would want the new objects necessary for the updated\nsuperproject, which means a submodule that is init'ed (whether it is\nvia \"git submodule init\" or the submodule.autoinit variable) must be\nupdated.\n\nSo I am not sure why a user wants to disable autoupdate in the first\nplace.  For the same reason, setting submodule.*.update to none\nwould not make much sense, either.  Perhaps I am missing something.\n\nUnless the user is very conservative and suspects that these\nrecursive behaviour we are going to bolt on to various commands\ncould be buggy and untrustworthy, in which case the user might want\nto manually run \"git submodule update\", or even run \"git fetch\"\nafter going there while bypassing the whole \"git submodule\".  But I\ndo not think that is healthy in the longer run.\n"},{"id":"243412","messageId":"20140605184340.GA31746@odin.tremily.us","threadId":"36825","inReplyTo":"xmqq4mzzte2z.fsf@gitster.dls.corp.google.com","subject":"Re: Re: [RFC PATCH] clone: add clone.recursesubmodules config option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-06-05T18:43:40Z","receivedAt":"2014-06-05T18:43:40Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, Jun 05, 2014 at 11:18:28AM -0700, Junio C Hamano wrote:\n> Jens Lehmann <Jens.Lehmann@web.de> writes:\n> > We had two settings in mind,...\n> > So what if clone would just do an \"git submodule init\" for now when\n> > \"submodule.autoinit\" is set but \"submodule.autoupdate\" isn't [?]\n> > ... and a single \"submodule.auto\" setting would be what users really want?\n> \n> I do not offhand think of a sensible scenario where you want to init\n> a submodule once but do not want to update it when the superproject\n> changes.  Even if the user uses the mode to detach the submodule\n> HEAD, i.e. the branches in submodules do not matter and the whole\n> tree is described by the superproject's commit and gitlinks recorded\n> in it, the user would want the new objects necessary for the updated\n> superproject, which means a submodule that is init'ed (whether it is\n> via \"git submodule init\" or the submodule.autoinit variable) must be\n> updated.\n\nI agreed that once we have the ability to do so, autoupdating any\ninitialized submodules should be automatic and non-optional.  However,\nmaking it optional during a transition period while the ability gets\nfleshed out would make sense too (so checkout-mode folks can opt in\nbefore we clobber the local-branch folks ;).\n\nCeers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"243445","messageId":"20140606052601.GB77405@book.hvoigt.net","threadId":"36825","inReplyTo":"xmqq4mzzte2z.fsf@gitster.dls.corp.google.com","subject":"Re: Re: [RFC PATCH] clone: add clone.recursesubmodules config option","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2014-06-06T05:26:01Z","receivedAt":"2014-06-06T05:26:01Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Thu, Jun 05, 2014 at 11:18:28AM -0700, Junio C Hamano wrote:\n> Jens Lehmann <Jens.Lehmann@web.de> writes:\n> > We had two settings in mind,...\n> > So what if clone would just do an \"git submodule init\" for now when\n> > \"submodule.autoinit\" is set but \"submodule.autoupdate\" isn't [?]\n> > ... and a single \"submodule.auto\" setting would be what users really want?\n> \n> I do not offhand think of a sensible scenario where you want to init\n> a submodule once but do not want to update it when the superproject\n> changes.  Even if the user uses the mode to detach the submodule\n> HEAD, i.e. the branches in submodules do not matter and the whole\n> tree is described by the superproject's commit and gitlinks recorded\n> in it, the user would want the new objects necessary for the updated\n> superproject, which means a submodule that is init'ed (whether it is\n> via \"git submodule init\" or the submodule.autoinit variable) must be\n> updated.\n> \n> So I am not sure why a user wants to disable autoupdate in the first\n> place.  For the same reason, setting submodule.*.update to none\n> would not make much sense, either.  Perhaps I am missing something.\n> \n> Unless the user is very conservative and suspects that these\n> recursive behaviour we are going to bolt on to various commands\n> could be buggy and untrustworthy, in which case the user might want\n> to manually run \"git submodule update\", or even run \"git fetch\"\n> after going there while bypassing the whole \"git submodule\".  But I\n> do not think that is healthy in the longer run.\n\nI think autoupdate is mainly there for the transition phase. Since\nsubmodule can e.g. contain a lot of files a checkout would take much\nlonger. Similar to when Jens implemented the recursive diff, many people\nwere annoyed by the new files showing up and some with the impact on\nperformance (thats why we have the --ignore-submodules option).\n\nIn case of very big submodules and people already ignore their diff it\nmight even be necessary that the update is only done manually. E.g. for\na big media repository.\n\nCheers Heiko\n"},{"id":"243447","messageId":"20140606055430.GC77405@book.hvoigt.net","threadId":"36825","inReplyTo":"539020D1.1090601@gmail.com","subject":"Re: Re: [RFC PATCH] clone: add clone.recursesubmodules config option","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2014-06-06T05:54:30Z","receivedAt":"2014-06-06T05:54:30Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Thu, Jun 05, 2014 at 07:48:33PM +1200, Chris Packham wrote:\n> On 05/06/14 07:42, Heiko Voigt wrote:\n> > I like this idea of specifying different \"views\" by giving tags. But\n> > does it rule out a boolean clone.recursesubmodules? For the simple case\n> > some people might not want to worry about specifying tags but just want\n> > to configure: \"Yes give me everything\". So if we were to do this I would\n> > like it if we could have both. Also because the option for clone is\n> > --recurse-submodules and our typical schema is that a configuration\n> > option is named similar so clone.recursesubmodules would fit here.\n> \n> Maybe using a glob pattern would work.\n> \n> The user might say\n> \n>      [clone]\n>          recursesubmodules = x86*\n> \n> And .gitmodules might say\n> \n>      [submodule \"foo\"]\n>          tags = x86_64\n>      [submodule \"bar\"]\n>          tags = x86\n>      [submodule \"frotz\"]\n>          tags = powerpc\n> \n> For the \"Yes give me everything\" case the user could say\n> \n>      [clone]\n>          recursesubmodules = *\n\nThats interesting. Lets me/us think about that a little more.\n\n> > So either we do this \"magically\" and all valid boolean values are\n> > forbidden as tags or we would need a different config option. Further\n> > thinking about it: Maybe a general option that does not only apply to\n> > clone would suit the \"views\" use-case more. E.g. \"submodule.tags\" or\n> > similar.\n> > \n> > Also please note: We have been talking about adding two configurations\n> > for submodules:\n> > \n> > \tsubmodule.\"name\".autoclone (IIRC)\n> > \n> > I am not sure whether that was the correct name, but this option should\n> > tell recursive fetch / clone whether to automatically clone a submodule\n> > when it appears on a fetch in the history.\n> > \n> > \tsubmodule.\"name\".autoinit\n> > \n> > And this one is for recursive checkout and tells whether an appearing\n> > submodule should automatically be initialized.\n> > \n> > These options fullfill a similar use-case and are planned for the future\n> > when recursive fetch/clone and checkout are in place (which is not that\n> > far away). We might need to rethink these to incoporate the \"views from\n> > tags\" idea nicely and since we do not want a configuration nightmare.\n> \n> I'm a little confused at how autoclone and autoinit differ. Aren't they\n> the same? i.e. when this module appears grab it by default. I see\n> autoupdate as a little different meaning update it if it's been\n> initialised. Also does autoinit imply autoupdate?\n\nautoclone is about cloning the history of submodules. So e.g. when a\nsubmodule first appears in the superprojects history whether it should\nautomatically be cloned to .git/modules.\n\nautoinit is all about the checkout phase. When a commit with a new\nsubmodule is checked out: Should that new submodule be automatically\ninitialised?\n\nAs far as autoupdate is concerned: Maybe autoinit can imply that it is\nenabled, yes. But I guess we still need autoupdate for the case of big\nsubmodules that cause to much performance trouble if updated by every\ncheckout.\n\nSo its actually three values: autoclone, autoinit, autoupdate. Damn,\nthese configurations become more complicated everytime. Maybe we should\ntry to clean them, up once we have everything, with Git 3.0 ;-) If\nanyone has an idea how to get rid of some right now...\n\nRadically different thinking: How about just one: submodule.auto =\ntrue/false configuration and that means you opt in to doing everything\nas automatic as possible. Since we are still implementing we could stick\na prominent warning in the documentation that the user should be\nprepared for behavioral changes.\n\nOnce everybody is happy with that we could switch the default from false\nto true.\n\n> At $dayjob we have a superproject which devs clone this has submodules\n> for the important and/or high touch repositories. We have other\n> repositories that are normally build from a tarball (or not built at\n> all) but we can build them from external repositories if needed. The\n> latter case is painfully manual. If autoinit/autoupdate existed we'd\n> probably setup out projects with.\n> \n>     [submodule \"linux\"]\n>         autoinit = true\n> \tautoupdate = true\n>     [submodule \"userland\"]\n>         autoinit = true\n> \tautoupdate = true\n>     [submodule \"not-used-that-much\"]\n> \tautoupdate = true\n> \n> We probably wouldn't make use of tags because we're building complete\n> embedded systems and generally want everything, even if we are doing\n> most of our work on a particular target we need to do builds for other\n> targets for sanity checks.\n\nYep thats exactly what we already do at $dayjob but with\nsubmodule.*.update=none. Since that conveniently also disables the\ninitialisation, developers only get the basic code and not everyone\nneeds to have the media and some big external libs.\n\nI would reuse 'update' in the long run. But I guess for the transition\nwe will need the extra autoupdate one to keep annoyance levels low.\n\nWe currently also do not have real use cases for the tags/views\nscenario, but as repositories grow I can see that it could be useful so\nI would like it if we could keep the configuration open to that.\n\nCheers Heiko\n"},{"id":"243501","messageId":"xmqqmwdqq9lg.fsf@gitster.dls.corp.google.com","threadId":"36825","inReplyTo":"20140606055430.GC77405@book.hvoigt.net","subject":"Re: [RFC PATCH] clone: add clone.recursesubmodules config option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-06-06T16:35:55Z","receivedAt":"2014-06-06T16:35:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Heiko Voigt <hvoigt@hvoigt.net> writes:\n\n> On Thu, Jun 05, 2014 at 07:48:33PM +1200, Chris Packham wrote:\n> ...\n>> I'm a little confused at how autoclone and autoinit differ. Aren't they\n>> the same? i.e. when this module appears grab it by default. I see\n>> autoupdate as a little different meaning update it if it's been\n>> initialised. Also does autoinit imply autoupdate?\n>\n> autoclone is about cloning the history of submodules. So e.g. when a\n> submodule first appears in the superprojects history whether it should\n> automatically be cloned to .git/modules.\n>\n> autoinit is all about the checkout phase. When a commit with a new\n> submodule is checked out: Should that new submodule be automatically\n> initialised?\n>\n> As far as autoupdate is concerned: Maybe autoinit can imply that it is\n> enabled, yes. But I guess we still need autoupdate for the case of big\n> submodules that cause to much performance trouble if updated by every\n> checkout.\n\n> So its actually three values: autoclone, autoinit, autoupdate. Damn,\n> these configurations become more complicated everytime.\n\nI suspect that as an end-user you do not need to set all three in\nmost cases.  Just like an unspecified autoupdate can default to\nwhatever autoinit setting for the submodule is, because it is less\nlikely that a user wants to have a submodule checked out *and* leave\nit stale, an unspecified autoinit can default to the autoclone\nsetting, because it is less likely that a user who does not want to\nhave a checkout would want to spend network bandwidth to clone it.\n"},{"id":"243622","messageId":"5395B3D3.9060501@web.de","threadId":"36825","inReplyTo":"20140606055430.GC77405@book.hvoigt.net","subject":"Re: [RFC PATCH] clone: add clone.recursesubmodules config option","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2014-06-09T13:17:07Z","receivedAt":"2014-06-09T13:17:07Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 06.06.2014 07:54, schrieb Heiko Voigt:\n> On Thu, Jun 05, 2014 at 07:48:33PM +1200, Chris Packham wrote:\n>> On 05/06/14 07:42, Heiko Voigt wrote:\n>>> So either we do this \"magically\" and all valid boolean values are\n>>> forbidden as tags or we would need a different config option. Further\n>>> thinking about it: Maybe a general option that does not only apply to\n>>> clone would suit the \"views\" use-case more. E.g. \"submodule.tags\" or\n>>> similar.\n>>>\n>>> Also please note: We have been talking about adding two configurations\n>>> for submodules:\n>>>\n>>> \tsubmodule.\"name\".autoclone (IIRC)\n>>>\n>>> I am not sure whether that was the correct name, but this option should\n>>> tell recursive fetch / clone whether to automatically clone a submodule\n>>> when it appears on a fetch in the history.\n>>>\n>>> \tsubmodule.\"name\".autoinit\n>>>\n>>> And this one is for recursive checkout and tells whether an appearing\n>>> submodule should automatically be initialized.\n>>>\n>>> These options fullfill a similar use-case and are planned for the future\n>>> when recursive fetch/clone and checkout are in place (which is not that\n>>> far away). We might need to rethink these to incoporate the \"views from\n>>> tags\" idea nicely and since we do not want a configuration nightmare.\n>>\n>> I'm a little confused at how autoclone and autoinit differ. Aren't they\n>> the same? i.e. when this module appears grab it by default. I see\n>> autoupdate as a little different meaning update it if it's been\n>> initialised. Also does autoinit imply autoupdate?\n> \n> autoclone is about cloning the history of submodules. So e.g. when a\n> submodule first appears in the superprojects history whether it should\n> automatically be cloned to .git/modules.\n> \n> autoinit is all about the checkout phase. When a commit with a new\n> submodule is checked out: Should that new submodule be automatically\n> initialised?\n\nTo me those two only make sense together, so I see them as a single\noption. But then maybe some developers would like to clone everything\nso they are plane-safe in case they intend to do \"git submodule\nupdate --init\" later at 30.000 feet without internet access ... so\nyes, technically we have three distinct steps: clone, init & update.\n\n> As far as autoupdate is concerned: Maybe autoinit can imply that it is\n> enabled, yes. But I guess we still need autoupdate for the case of big\n> submodules that cause to much performance trouble if updated by every\n> checkout.\n> \n> So its actually three values: autoclone, autoinit, autoupdate. Damn,\n> these configurations become more complicated everytime. Maybe we should\n> try to clean them, up once we have everything, with Git 3.0 ;-) If\n> anyone has an idea how to get rid of some right now...\n\nI suspect that once they are introduced we'll never be able to get\nrid of them again ;-)\n\n> Radically different thinking: How about just one: submodule.auto =\n> true/false configuration and that means you opt in to doing everything\n> as automatic as possible. Since we are still implementing we could stick\n> a prominent warning in the documentation that the user should be\n> prepared for behavioral changes.\n> \n> Once everybody is happy with that we could switch the default from false\n> to true.\n\nI like that. (And if we really need /clone-but-no-init-or-update/ or\n/clone-and-init-but-no-update/ settings later we could add two new\nvalues additionally to true/false to make that work with a single\nsetting too). So I'm convinced that a single option is the way to go.\n\n>> At $dayjob we have a superproject which devs clone this has submodules\n>> for the important and/or high touch repositories. We have other\n>> repositories that are normally build from a tarball (or not built at\n>> all) but we can build them from external repositories if needed. The\n>> latter case is painfully manual. If autoinit/autoupdate existed we'd\n>> probably setup out projects with.\n>>\n>>     [submodule \"linux\"]\n>>         autoinit = true\n>> \tautoupdate = true\n>>     [submodule \"userland\"]\n>>         autoinit = true\n>> \tautoupdate = true\n>>     [submodule \"not-used-that-much\"]\n>> \tautoupdate = true\n>>\n>> We probably wouldn't make use of tags because we're building complete\n>> embedded systems and generally want everything, even if we are doing\n>> most of our work on a particular target we need to do builds for other\n>> targets for sanity checks.\n> \n> Yep thats exactly what we already do at $dayjob but with\n> submodule.*.update=none. Since that conveniently also disables the\n> initialisation, developers only get the basic code and not everyone\n> needs to have the media and some big external libs.\n> \n> I would reuse 'update' in the long run. But I guess for the transition\n> we will need the extra autoupdate one to keep annoyance levels low.\n\nI'm not sure reusing 'update' is going to work: 'update' currently\ncontrols what \"git submodule update\" will do: nothing, checkout,\nmerge or rebase (and we shouldn't change that because of backwards\ncompatibility). We're talking about a new setting telling regular\ngit commands to do the submodule work tree update without having to\nmanually call \"git submodule update\". And I believe we'll always\nneed 'update' as it is for people who'll want to do a manual \"git\nsubmodule update\", especially when we change the default of\n'submodule.auto' to true in 3.0.\n\nAnd by the way: wouldn't it make more sense to tell the user /what/\nwe do automatically? So maybe 'submodule.autoupdate' is a better\nname for the new switch? The fact that it also does clone and init\nunder the hood looks more like a technical detail to the user, no?\nAnd I'd like to avoid users uttering \"auto-what?\" when they hear\nabout this setting ;-) And it would make clear that 'update' is\nwhat we do and 'autoupdate' makes it happen without having to call\n\"git submodule update\".\n"},{"id":"243687","messageId":"20140609232725.GA9047@odin.tremily.us","threadId":"36825","inReplyTo":"5395B3D3.9060501@web.de","subject":"Re: Re: [RFC PATCH] clone: add clone.recursesubmodules config option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-06-09T23:27:25Z","receivedAt":"2014-06-09T23:27:25Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Mon, Jun 09, 2014 at 03:17:07PM +0200, Jens Lehmann wrote:\n> And by the way: wouldn't it make more sense to tell the user /what/\n> we do automatically? So maybe 'submodule.autoupdate' is a better\n> name for the new switch?\n\nOr autocheckout?  No need to preserve submodule-specific jargon when\nwe have a perfectly acceptable word for this in the core interface ;).\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"303092","messageId":"57F27B02.8080803@game-point.net","threadId":"36825","inReplyTo":"1401874256-13332-1-git-send-email-judge.packham@gmail.com","subject":"Re: [RFC PATCH] clone: add clone.recursesubmodules config option","fromName":"Jeremy Morton","fromEmail":"admin@game-point.net","sentAt":"2016-10-03T15:36:34Z","receivedAt":"2016-10-03T15:38:22Z","isPatch":true,"sender":{"key":"admin@game-point.net","avatar":null},"body":"Did this ever get anywhere?  Can we recursively update submodules with \n\"git pull\" in the supermodule now?\n\n-- \nBest regards,\nJeremy Morton (Jez)\n\nOn 04/06/2014 10:30, Chris Packham wrote:\n> Add a config option that will cause clone to recurse into submodules as\n> if the --recurse-submodules option had been specified on the command\n> line. This can be overridden with the --no-recurse-submodules option.\n>\n> Signed-off-by: Chris Packham<judge.packham@gmail.com>\n> ---\n> On 04/06/14 09:05, Junio C Hamano wrote:\n>>> Mara Kim<mara.kim@vanderbilt.edu>  writes:\n>>>\n>>>> Apologies if this question has been asked already, but what is the\n>>>> reasoning behind making git clone not recursive (--recursive) by\n>>>> default?\n>>>\n>>> The primary reason why submodules are separate repositories is not\n>>> to require people to have everything.  Some people want recursive,\n>>> some others don't, and the world is not always \"majority wins\" (not\n>>> that I am saying that majority will want recursive).\n>>>\n>>> Inertia, aka backward compatibility and not surprising existing\n>>> users, plays some role when deciding the default.\n>>>\n>>> Also, going --recursive when the user did not want is a lot more\n>>> expensive mistake to fix than not being --recursive when the user\n>>> wanted to.\n>>\n>> Having said all that, I do not mean to say that I am opposed to\n>> introduce some mechanism to let the users express their preference\n>> between recursive and non-recursive better, so that \"git clone\"\n>> without an explicit --recursive (or --no-recursive) can work to\n>> their taste.  A configuration in $HOME/.gitconfig might be a place\n>> to start, even though that has the downside of assuming that the\n>> given user would want to use the same settings for all his projects,\n>> which may not be the case in practice.\n>\n> And here's a quick proof of concept. Not sure about the config variable name\n> and it could probably do with a negative test as well.\n>\n>   builtin/clone.c              |  9 +++++++++\n>   t/t7407-submodule-foreach.sh | 17 +++++++++++++++++\n>   2 files changed, 26 insertions(+)\n>\n> diff --git a/builtin/clone.c b/builtin/clone.c\n> index b12989d..92aea81 100644\n> --- a/builtin/clone.c\n> +++ b/builtin/clone.c\n> @@ -734,6 +734,14 @@ static void write_refspec_config(const char* src_ref_prefix,\n>   \tstrbuf_release(&value);\n>   }\n>\n> +static int git_clone_config(const char *key, const char *value, void *data)\n> +{\n> +\tif (!strcmp(key, \"clone.recursesubmodules\"))\n> +\t\toption_recursive = git_config_bool(key, value);\n> +\n> +\treturn 0;\n> +}\n> +\n>   int cmd_clone(int argc, const char **argv, const char *prefix)\n>   {\n>   \tint is_bundle = 0, is_local;\n> @@ -759,6 +767,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n>   \tjunk_pid = getpid();\n>\n>   \tpacket_trace_identity(\"clone\");\n> +\tgit_config(git_clone_config, NULL);\n>   \targc = parse_options(argc, argv, prefix, builtin_clone_options,\n>   \t\t\t     builtin_clone_usage, 0);\n>\n> diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh\n> index 7ca10b8..fc2c189 100755\n> --- a/t/t7407-submodule-foreach.sh\n> +++ b/t/t7407-submodule-foreach.sh\n> @@ -307,6 +307,23 @@ test_expect_success 'use \"update --recursive nested1\" to checkout all submodules\n>   \t)\n>   '\n>\n> +test_expect_success 'use \"git clone\" with clone.recursesubmodules to checkout all submodules' '\n> +\tgit config --local clone.recursesubmodules true&&\n> +\tgit clone super clone7&&\n> +\t(\n> +\t\tcd clone7&&\n> +\t\tgit rev-parse --resolve-git-dir .git&&\n> +\t\tgit rev-parse --resolve-git-dir sub1/.git&&\n> +\t\tgit rev-parse --resolve-git-dir sub2/.git&&\n> +\t\tgit rev-parse --resolve-git-dir sub3/.git&&\n> +\t\tgit rev-parse --resolve-git-dir nested1/.git&&\n> +\t\tgit rev-parse --resolve-git-dir nested1/nested2/.git&&\n> +\t\tgit rev-parse --resolve-git-dir nested1/nested2/nested3/.git&&\n> +\t\tgit rev-parse --resolve-git-dir nested1/nested2/nested3/submodule/.git\n> +\t)&&\n> +\tgit config --local --unset clone.recursesubmodules\n> +'\n> +\n>   test_expect_success 'command passed to foreach retains notion of stdin' '\n>   \t(\n>   \t\tcd super&&\n"},{"id":"303098","messageId":"CAGZ79kbNVy7VFj31m7VKZYP6xphkV_d9Y1x9Q0_=5PZ+_068HA@mail.gmail.com","threadId":"36825","inReplyTo":"57F27B02.8080803@game-point.net","subject":"Re: [RFC PATCH] clone: add clone.recursesubmodules config option","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-10-03T17:18:32Z","receivedAt":"2016-10-03T17:18:38Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Mon, Oct 3, 2016 at 8:36 AM, Jeremy Morton <admin@game-point.net> wrote:\n> Did this ever get anywhere?  Can we recursively update submodules with \"git\n> pull\" in the supermodule now?\n\nI think the idea is sound.\n\n>> diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh\n>> index 7ca10b8..fc2c189 100755\n>> --- a/t/t7407-submodule-foreach.sh\n>> +++ b/t/t7407-submodule-foreach.sh\n\nNot sure if t7407-submodule-foreach.sh is the best place to put these tests,\nas it is not `submodule foreach`, maybe put it into 7400 (though that\nis larger already)\n\n>> +test_expect_success 'use \"git clone\" with clone.recursesubmodules to\n>> checkout all submodules' '\n>> +       git config --local clone.recursesubmodules true&&\n\nNit of the day:\nI think we prefer a single white space between the line and the ending\n&&.\n\nNo need for --local as that is the default.\nHowever I'd propose to use test_config here,\nas then the option is cleaned up after the test\nautomatically.\n\n>> +       git clone super clone7&&\n>> +       (\n>> +               cd clone7&&\n>> +               git rev-parse --resolve-git-dir .git&&\n>> +               git rev-parse --resolve-git-dir sub1/.git&&\n>> +               git rev-parse --resolve-git-dir sub2/.git&&\n>> +               git rev-parse --resolve-git-dir sub3/.git&&\n>> +               git rev-parse --resolve-git-dir nested1/.git&&\n>> +               git rev-parse --resolve-git-dir nested1/nested2/.git&&\n>> +               git rev-parse --resolve-git-dir\n>> nested1/nested2/nested3/.git&&\n>> +               git rev-parse --resolve-git-dir\n>> nested1/nested2/nested3/submodule/.git\n>> +       )&&\n>> +       git config --local --unset clone.recursesubmodules\n\nNo need to unset it here when test_config is used.\n\nWe'd maybe would want to also test that\ngit -c clone.recursesubmodules clone --no-recursive ...\nworks as expected (the --no-recursive taking precedence\nover the config option)\n"},{"id":"303203","messageId":"20161004114117.GC20309@book.hvoigt.net","threadId":"36825","inReplyTo":"CAGZ79kbNVy7VFj31m7VKZYP6xphkV_d9Y1x9Q0_=5PZ+_068HA@mail.gmail.com","subject":"Re: [RFC PATCH] clone: add clone.recursesubmodules config option","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2016-10-04T11:41:17Z","receivedAt":"2016-10-04T11:41:27Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Mon, Oct 03, 2016 at 10:18:32AM -0700, Stefan Beller wrote:\n> On Mon, Oct 3, 2016 at 8:36 AM, Jeremy Morton <admin@game-point.net> wrote:\n> > Did this ever get anywhere?  Can we recursively update submodules with \"git\n> > pull\" in the supermodule now?\n> \n> I think the idea is sound.\n\nI am confused there is nothing handling *pull* here? This patch was\nabout clone. Handling 'pull' is a much bigger topic[1].\n\nCheers Heiko\n\n[1] https://github.com/jlehmann/git-submod-enhancements/wiki/Recursive-submodule-checkout\n"},{"id":"325452","messageId":"598215C8.4000100@game-point.net","threadId":"36825","inReplyTo":"20140606052601.GB77405@book.hvoigt.net","subject":"Re: [RFC PATCH] clone: add clone.recursesubmodules config option","fromName":"Jeremy Morton","fromEmail":"admin@game-point.net","sentAt":"2017-08-02T18:11:20Z","receivedAt":"2017-08-02T18:21:34Z","isPatch":true,"sender":{"key":"admin@game-point.net","avatar":null},"body":"Did this ever get anywhere?  If not why not?  It would be very useful \nto me to be able to clone recursively by default, especially \nconsidering you can't use 'alias' to override the existing 'clone' \ncommand.\n\n-- \nBest regards,\nJeremy Morton (Jez)\n\nOn 06/06/2014 06:26, Heiko Voigt wrote:\n> On Thu, Jun 05, 2014 at 11:18:28AM -0700, Junio C Hamano wrote:\n>> Jens Lehmann<Jens.Lehmann@web.de>  writes:\n>>> We had two settings in mind,...\n>>> So what if clone would just do an \"git submodule init\" for now when\n>>> \"submodule.autoinit\" is set but \"submodule.autoupdate\" isn't [?]\n>>> ... and a single \"submodule.auto\" setting would be what users really want?\n>>\n>> I do not offhand think of a sensible scenario where you want to init\n>> a submodule once but do not want to update it when the superproject\n>> changes.  Even if the user uses the mode to detach the submodule\n>> HEAD, i.e. the branches in submodules do not matter and the whole\n>> tree is described by the superproject's commit and gitlinks recorded\n>> in it, the user would want the new objects necessary for the updated\n>> superproject, which means a submodule that is init'ed (whether it is\n>> via \"git submodule init\" or the submodule.autoinit variable) must be\n>> updated.\n>>\n>> So I am not sure why a user wants to disable autoupdate in the first\n>> place.  For the same reason, setting submodule.*.update to none\n>> would not make much sense, either.  Perhaps I am missing something.\n>>\n>> Unless the user is very conservative and suspects that these\n>> recursive behaviour we are going to bolt on to various commands\n>> could be buggy and untrustworthy, in which case the user might want\n>> to manually run \"git submodule update\", or even run \"git fetch\"\n>> after going there while bypassing the whole \"git submodule\".  But I\n>> do not think that is healthy in the longer run.\n>\n> I think autoupdate is mainly there for the transition phase. Since\n> submodule can e.g. contain a lot of files a checkout would take much\n> longer. Similar to when Jens implemented the recursive diff, many people\n> were annoyed by the new files showing up and some with the impact on\n> performance (thats why we have the --ignore-submodules option).\n>\n> In case of very big submodules and people already ignore their diff it\n> might even be necessary that the update is only done manually. E.g. for\n> a big media repository.\n>\n> Cheers Heiko\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"325477","messageId":"CAGZ79kYy3oBvKXNDnBj01AoOz_JMEg409OTOm+rePz2q+14Hdw@mail.gmail.com","threadId":"36825","inReplyTo":"598215C8.4000100@game-point.net","subject":"Re: [RFC PATCH] clone: add clone.recursesubmodules config option","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-02T20:34:58Z","receivedAt":"2017-08-02T20:35:06Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Aug 2, 2017 at 11:11 AM, Jeremy Morton <admin@game-point.net> wrote:\n> Did this ever get anywhere?  If not why not?  It would be very useful to me\n> to be able to clone recursively by default, especially considering you can't\n> use 'alias' to override the existing 'clone' command.\n>\n\nNote that there is 3c548de378 (Merge branch 'sb/submodule-blanket-recursive',\n2017-06-13), which adds recursing into submodules to a couple of commands.\n\nclone is not one of them, because at that time I thought you'd want to select\nexplicitly at clone time which submodules you want. Unlike most other commands\nthat can recurse into submodules, clone supports a pathspec for the recurse\nparameter, such that you can express a fine grained selection of submodules\nthat you are interested in.\n\nI wonder if submodule.recurse is set if we'd just want to recurse into\nall submodules for clone? That may have negative consequences though\nas people may have forgotten that they set that config a long time ago and then\nare surprised to get so many submodules.\n"}]}