{"thread":{"id":"44816","subject":"core.sshCommand and url.*.insteadOf for submodules","startedAt":"2017-01-05T10:28:48Z","lastAt":"2017-01-05T17:34:10Z","messageCount":4,"participants":["Stefan Schindler","Stefan Beller","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"308816","messageId":"17f2724d-7001-203e-f0b5-cf586703a41a@boxbox.org","threadId":"44816","inReplyTo":null,"subject":"core.sshCommand and url.*.insteadOf for submodules","fromName":"Stefan Schindler","fromEmail":"stsch@boxbox.org","sentAt":"2017-01-05T10:09:55Z","receivedAt":"2017-01-05T10:28:48Z","isPatch":false,"sender":{"key":"stsch@boxbox.org","avatar":null},"body":"Hello mailing list,\n\nit seems like that the `core.sshCommand` and `url.*.insteadOf`\nconfiguration settings do not apply to `git submodule update --init`\n(and probably related) calls.\n\nIs this intentional?\n\nMy scenario is as follows: I use 2 SSH keys for GitHub, for private and\nwork-related repositories. My default key is my private key. So when I\nclone a work repository and try getting the submodules, `git submodule\nupdate --init` fails. This is also the case when setting\n`core.sshCommand` and `url.*.insteadOf` (useful for substituting\n\"github.com\" by some ~/.ssh/config'ured host).\n\nGreetings,\nStefan Schindler\n"},{"id":"308820","messageId":"CAGZ79kb8TTaJBmVCWK3jnr4RvGjmfmsj3-ieT87wzyFLYi5frQ@mail.gmail.com","threadId":"44816","inReplyTo":"17f2724d-7001-203e-f0b5-cf586703a41a@boxbox.org","subject":"Re: core.sshCommand and url.*.insteadOf for submodules","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-01-05T13:53:30Z","receivedAt":"2017-01-05T13:53:36Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Jan 5, 2017 at 2:09 AM, Stefan Schindler wrote:\n> Hello mailing list,\n>\n> it seems like that the `core.sshCommand` and `url.*.insteadOf`\n> configuration settings do not apply to `git submodule update --init`\n> (and probably related) calls.\n>\n> Is this intentional?\n\nThe original design of submodules was to have a submodule to be a\nstandalone repository, such that e.g. its options are read from its own\nconfig file. So the original vision was to decouple the init and clone of the\nsubmodule to allow the user to change the settings:\n\n git submodule init\n # copies the submodule..URL from .gitmodules to .git/config\n # user realizes that the URL is not a good idea, such that\n git config submodule..url http://${company-mirror}/submodule\n # now the url is fixed so\n git submodule update\n\nI guess it could be a good idea to propagate some settings from the\nsuperproject to the submodules when they are cloned.\n\n>\n> My scenario is as follows: I use 2 SSH keys for GitHub, for private and\n> work-related repositories. My default key is my private key. So when I\n> clone a work repository and try getting the submodules, `git submodule\n> update --init` fails. This is also the case when setting\n> `core.sshCommand` and `url.*.insteadOf` (useful for substituting\n> \"github.com\" by some ~/.ssh/config'ured host).\n>\n\nwhich is why e.g.\ngit config --global url.https://github.com/.insteadOf git://github.com/\nis not your preferred way here.\n\nThere was some discussion a couple of weeks ago, which settings\nshould be kept when recursing into submodules, Jacob and Jeff cc'd.\n\n> Greetings,\n> Stefan Schindler\n"},{"id":"308826","messageId":"20170105170214.6fmsbj6ltbmpvcfb@sigill.intra.peff.net","threadId":"44816","inReplyTo":"CAGZ79kb8TTaJBmVCWK3jnr4RvGjmfmsj3-ieT87wzyFLYi5frQ@mail.gmail.com","subject":"Re: core.sshCommand and url.*.insteadOf for submodules","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-01-05T17:02:15Z","receivedAt":"2017-01-05T17:30:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jan 05, 2017 at 05:53:30AM -0800, Stefan Beller wrote:\n\n> > My scenario is as follows: I use 2 SSH keys for GitHub, for private and\n> > work-related repositories. My default key is my private key. So when I\n> > clone a work repository and try getting the submodules, `git submodule\n> > update --init` fails. This is also the case when setting\n> > `core.sshCommand` and `url.*.insteadOf` (useful for substituting\n> > \"github.com\" by some ~/.ssh/config'ured host).\n> \n> which is why e.g.\n> git config --global url.https://github.com/.insteadOf git://github.com/\n> is not your preferred way here.\n> \n> There was some discussion a couple of weeks ago, which settings\n> should be kept when recursing into submodules, Jacob and Jeff cc'd.\n\nThe only discussion I recall was from last May. But that was about \"-c\"\nconfig on the command-line, and the end decision was that we pass it all\ndown to submodules, per 89044baa8b (submodule: stop sanitizing config\noptions, 2016-05-04).\n\nI think the problem here is more about propagating options from the\nsuperproject's repo-level config into the submodules. AFAIK we do not do\nthat at all, but I may have missed some patches in that area.\n\nAnother approach would be conditional config includes based on the repo\npath. With the patches discussed in [1], you could do something like:\n\n git config --global include./path/to/work/repos.path .gitconfig-work\n git config -f ~/.gitconfig-work url.foo.insteadOf bar\n\n-Peff\n\n[1] http://public-inbox.org/git/20160626070617.30211-1-pclouds@gmail.com/\n"},{"id":"308827","messageId":"CAGZ79kYPuqYTAFe9c0kQxrREfEPtuT_OT4ZsFAz-c1UPW3k9yQ@mail.gmail.com","threadId":"44816","inReplyTo":"20170105170214.6fmsbj6ltbmpvcfb@sigill.intra.peff.net","subject":"Re: core.sshCommand and url.*.insteadOf for submodules","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-01-05T17:30:51Z","receivedAt":"2017-01-05T17:34:10Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Jan 5, 2017 at 9:02 AM, Jeff King wrote:\n> On Thu, Jan 05, 2017 at 05:53:30AM -0800, Stefan Beller wrote:\n>\n>> > My scenario is as follows: I use 2 SSH keys for GitHub, for private and\n>> > work-related repositories. My default key is my private key. So when I\n>> > clone a work repository and try getting the submodules, `git submodule\n>> > update --init` fails. This is also the case when setting\n>> > `core.sshCommand` and `url.*.insteadOf` (useful for substituting\n>> > \"github.com\" by some ~/.ssh/config'ured host).\n>>\n>> which is why e.g.\n>> git config --global url.https://github.com/.insteadOf git://github.com/\n>> is not your preferred way here.\n>>\n>> There was some discussion a couple of weeks ago, which settings\n>> should be kept when recursing into submodules, Jacob and Jeff cc'd.\n>\n> The only discussion I recall was from last May. But that was about \"-c\"\n> config on the command-line, and the end decision was that we pass it all\n> down to submodules, per 89044baa8b (submodule: stop sanitizing config\n> options, 2016-05-04).\n\nOh, yeah that was the difference.\n\n>\n> I think the problem here is more about propagating options from the\n> superproject's repo-level config into the submodules. AFAIK we do not do\n> that at all, but I may have missed some patches in that area.\n\nAFAIK there were no such patches yet.\n\n>\n> Another approach would be conditional config includes based on the repo\n> path. With the patches discussed in [1], you could do something like:\n>\n> git config --global include./path/to/work/repos.path .gitconfig-work\n> git config -f ~/.gitconfig-work url.foo.insteadOf bar\n\nOr maybe we could specialize these patches to allow\nincludes from specific other repos, i.e. superproject(s) or worktrees.\n\n>\n> -Peff\n>\n> [1] http://public-inbox.org/git/20160626070617.30211-1-pclouds@gmail.com/\n"}]}