{"thread":{"id":"47363","subject":"git-clone ignores submodule.recurse configuration","startedAt":"2017-12-01T18:49:22Z","lastAt":"2017-12-04T20:02:42Z","messageCount":3,"participants":["Ralf Thielow","Brandon Williams","Stefan Beller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"333934","messageId":"CAN0XMOJnQX-gSnpHaiJUYr4X4-WT91oT3Xv3gDtKYjX7J3ObVw@mail.gmail.com","threadId":"47363","inReplyTo":null,"subject":"git-clone ignores submodule.recurse configuration","fromName":"Ralf Thielow","fromEmail":"ralf.thielow@gmail.com","sentAt":"2017-12-01T18:48:58Z","receivedAt":"2017-12-01T18:49:22Z","isPatch":false,"sender":{"key":"ralf.thielow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1275832?v=4"},"body":"Today I played around a bit with git submodules and noticed\nthat the very handy configuration \"submodule.recurse\" is not\nworking for the git-clone command.\n\n\"git help config\" tells me that submodule.recurse affects\nall commands that have a --recurse-submodules option.\ngit-clone seems to be an exception which is also mentioned in\na workflow example in Documentation/gitsubmodules.txt that\nsays:\n\n  # Unlike the other commands below clone still needs\n  # its own recurse flag:\n  git clone --recurse <URL> <directory>\n  cd <directory>\n\nSo this seems to be a known issue. Is someone already\nworking on this or has a plan to do it? Or is there a reason\nnot doing this for git-clone but for git-pull?\n"},{"id":"333939","messageId":"20171201214709.GA61710@google.com","threadId":"47363","inReplyTo":"CAN0XMOJnQX-gSnpHaiJUYr4X4-WT91oT3Xv3gDtKYjX7J3ObVw@mail.gmail.com","subject":"Re: git-clone ignores submodule.recurse configuration","fromName":"Brandon Williams","fromEmail":"bmwill@google.com","sentAt":"2017-12-01T21:47:09Z","receivedAt":"2017-12-01T21:47:17Z","isPatch":false,"sender":{"key":"bwilliams.eng@gmail.com","avatar":null},"body":"On 12/01, Ralf Thielow wrote:\n> Today I played around a bit with git submodules and noticed\n> that the very handy configuration \"submodule.recurse\" is not\n> working for the git-clone command.\n> \n> \"git help config\" tells me that submodule.recurse affects\n> all commands that have a --recurse-submodules option.\n> git-clone seems to be an exception which is also mentioned in\n> a workflow example in Documentation/gitsubmodules.txt that\n> says:\n> \n>   # Unlike the other commands below clone still needs\n>   # its own recurse flag:\n>   git clone --recurse <URL> <directory>\n>   cd <directory>\n> \n> So this seems to be a known issue. Is someone already\n> working on this or has a plan to do it? Or is there a reason\n> not doing this for git-clone but for git-pull?\n\nWhen we introduced the \"submodule.recurse\" config we explicitly had it\nnot work with clone because a recursive clone ends up pulling data from\nother sources aside from the URL the user explicitly provides.\nHistorically there have been a number of security related bugs with\nrespect to cloning submodules so we felt it was best to require a\nrecursive clone to be requested explicitly, at least for the time being.\n\n-- \nBrandon Williams\n"},{"id":"334084","messageId":"CAGZ79kaPFMQicmfhaWZ_BRyuSXCwTMYX_Jwk_aGSJDFr-_=xzg@mail.gmail.com","threadId":"47363","inReplyTo":"20171201214709.GA61710@google.com","subject":"Re: git-clone ignores submodule.recurse configuration","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-12-04T20:02:36Z","receivedAt":"2017-12-04T20:02:42Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Fri, Dec 1, 2017 at 1:47 PM, Brandon Williams <bmwill@google.com> wrote:\n> On 12/01, Ralf Thielow wrote:\n>> Today I played around a bit with git submodules and noticed\n>> that the very handy configuration \"submodule.recurse\" is not\n>> working for the git-clone command.\n\nThe rationale here is that submodule.recursive ought to make your\nconglomerate of repositories (superproject + some submodules)\nlook and feel like one giant repository.  Thinking further this sounds\nlike a user wants to set it globally, hence it may be expected to\nwork for fresh clones, too.\n\nHowever at clone time, we don't know which submodules the\nuser wants. The first submodule recursive switches were an\nall or nothing, but I think we need a better selection there.\nFor fetch there is an \"only-those-needed\" selection as\n\"on-demand\". Similar for push.\n\nFor clone we expected the user wanting to specify which\nsubmodules are interesting:\n\n  git clone --recurse-submodule=<pathspec>\n\n(Note to self: the `[=<pathspec]` part is deep down in the\nman page, not in the synopsis, we may want to put that\nmore prominently there)\n\nMaybe when submodule.recursive is set, we should assume\na pathspec of \".\" (everything), also see to `submodule.active`,\nwhich is set using the argument from git-clone.\n\n>> \"git help config\" tells me that submodule.recurse affects\n>> all commands that have a --recurse-submodules option.\n>> git-clone seems to be an exception which is also mentioned in\n>> a workflow example in Documentation/gitsubmodules.txt that\n>> says:\n>>\n>>   # Unlike the other commands below clone still needs\n>>   # its own recurse flag:\n>>   git clone --recurse <URL> <directory>\n>>   cd <directory>\n>>\n>> So this seems to be a known issue. Is someone already\n>> working on this or has a plan to do it? Or is there a reason\n>> not doing this for git-clone but for git-pull?\n>\n> When we introduced the \"submodule.recurse\" config we explicitly had it\n> not work with clone because a recursive clone ends up pulling data from\n> other sources aside from the URL the user explicitly provides.\n> Historically there have been a number of security related bugs with\n> respect to cloning submodules so we felt it was best to require a\n> recursive clone to be requested explicitly, at least for the time being.\n>\n> --\n> Brandon Williams\n"}]}