{"thread":{"id":"65474","subject":"How should submodules use different sshCommand during initial update?","startedAt":"2026-04-13T15:46:06Z","lastAt":"2026-04-14T07:25:55Z","messageCount":5,"participants":["Shibo Xia","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"541479","messageId":"CAAC4ekqE0rGTeZA3fPKYePr3=J8pHe-KORgn5W026J8AAhRRHw@mail.gmail.com","threadId":"65474","inReplyTo":null,"subject":"How should submodules use different sshCommand during initial update?","fromName":"Shibo Xia","fromEmail":"sbxia25@gmail.com","sentAt":"2026-04-13T15:45:53Z","receivedAt":"2026-04-13T15:46:06Z","isPatch":false,"body":"Hi,\n\nI have a question about submodules and SSH authentication during the initial\ngit submodule update --init step.\n\nI understand that there are already a few ways to influence SSH behavior:\n\ncore.sshCommand at the repository level\n\nGIT_SSH_COMMAND at the command level\n\nSSH host aliases and other settings in ~/.ssh/config\n\nHowever, I am running into a more specific problem with submodules.\n\nMy use case is that different submodules may need different SSH identities or\ndifferent SSH command settings. For an already initialized submodule, this can\nbe handled by entering the submodule repository and configuring it separately.\nBut during the initial git submodule update --init, the submodule does not yet\nhave its own local config, so there does not seem to be a clean per-submodule\nway to do this from Git itself.\n\nIn practice, the usual workaround seems to be putting the logic into SSH\nconfiguration and encoding it through host aliases or URL layout. That works,\nbut it also means the authentication behavior is kept outside Git's submodule\nconfiguration, even though the submodule remote itself is already configured in\nGit.\n\nSo my questions are:\n\nIs there already a recommended Git-native way to handle different\nsshCommand values for different submodules during initial clone/update?\n\nIf not, would support for something like a per-submodule sshCommand\nconfiguration be considered reasonable?\n\nHas this been discussed before specifically in the context of submodule\ninitialization, rather than per-remote SSH options in general?\n\nI am not sending a patch yet. I first wanted to ask whether this is considered\na real gap in current submodule behavior, or whether the expectation is that SSH\nconfiguration should remain the only solution here.\n\nBest regards,\nShibo Xia\n"},{"id":"541481","messageId":"xmqq1pgilufr.fsf@gitster.g","threadId":"65474","inReplyTo":"CAAC4ekqE0rGTeZA3fPKYePr3=J8pHe-KORgn5W026J8AAhRRHw@mail.gmail.com","subject":"Re: How should submodules use different sshCommand during initial update?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-04-13T16:02:48Z","receivedAt":"2026-04-13T16:02:51Z","isPatch":false,"body":"Shibo Xia writes:\n\n> My use case is that different submodules may need different SSH identities or\n> different SSH command settings.\n\nWould it help to do \"submodule init\" separately from \"submodule\nupdate\"? Then you have a chance to tweak the submodule.*.url\nconfiguration items in the superproject repository before the clone\nactually happens, I would imagine?\n"},{"id":"541518","messageId":"CAAC4ekquR+eCxTWifOR-X5hgd+rSen8eAUy8cxukouUE57xaoA@mail.gmail.com","threadId":"65474","inReplyTo":"xmqq1pgilufr.fsf@gitster.g","subject":"Re: How should submodules use different sshCommand during initial update?","fromName":"Shibo Xia","fromEmail":"sbxia25@gmail.com","sentAt":"2026-04-14T01:28:20Z","receivedAt":"2026-04-14T01:28:33Z","isPatch":false,"body":"Hi,\n\nYes, that would help as a workaround.\n\nIf I understand correctly, the idea would be to run:\n\ngit submodule init\n\nthen adjust submodule..url entries in the superproject config before\nthe actual clone happens, and only then run:\n\ngit submodule update\n\nThat does seem workable.\n\nMy concern is that this still solves the problem indirectly through URL\nrewriting / SSH host aliasing, rather than allowing the submodule's SSH\nbehavior itself to be configured more directly.\n\nSo I think this answers the practical \"how can this be done today?\" part,\nbut I am still wondering whether there is a reason Git should not support a\nmore direct per-submodule sshCommand-style configuration.\n\nThanks,\nShibo Xia\n\nJunio C Hamano 于2026年4月14日周二 00:02写道：\n>\n> Shibo Xia writes:\n>\n> > My use case is that different submodules may need different SSH identities or\n> > different SSH command settings.\n>\n> Would it help to do \"submodule init\" separately from \"submodule\n> update\"? Then you have a chance to tweak the submodule.*.url\n> configuration items in the superproject repository before the clone\n> actually happens, I would imagine?\n"},{"id":"541520","messageId":"20260414061558.GA2902306@coredump.intra.peff.net","threadId":"65474","inReplyTo":"CAAC4ekquR+eCxTWifOR-X5hgd+rSen8eAUy8cxukouUE57xaoA@mail.gmail.com","subject":"Re: How should submodules use different sshCommand during initial update?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-04-14T06:15:58Z","receivedAt":"2026-04-14T06:16:06Z","isPatch":false,"body":"On Tue, Apr 14, 2026 at 09:28:20AM +0800, Shibo Xia wrote:\n\n> My concern is that this still solves the problem indirectly through URL\n> rewriting / SSH host aliasing, rather than allowing the submodule's SSH\n> behavior itself to be configured more directly.\n> \n> So I think this answers the practical \"how can this be done today?\" part,\n> but I am still wondering whether there is a reason Git should not support a\n> more direct per-submodule sshCommand-style configuration.\n\nFor arbitrary per-submodule config, I can think of two approaches:\n\nOne is conditional includeIf directives in your ~/.gitconfig, matching\nbased on the submodule names. Like:\n\n # replace PARENT and SUBMODULE with your filesystem names\n [includeIf \"gitdir:**/PARENT/.git/modules/SUBMODULE\"]\n path = .gitconfig-submodule\n\nand then in ~/.gitconfig-submodule, you'd have:\n\n [core]\n sshCommand = whatever\n\nThis works, but it's kind of gross, as it depends on the module naming\nscheme (and isn't there a proposal to make these more opaque? I didn't\nfollow it). And of course you're not actually putting the config in the\nsubmodule, but rather polluting your user-level config with it (which\nmight or might not be preferable, depending on what you're trying to\nconfigure).\n\nThe second thought is that we faced the same problem with \"git clone\"\nitself: you might want to tweak some config after the repo is\ninitialized but before we fetch anything. We added the \"clone -c\" option\nfor that. It would seem reasonable to me to have a similar option that\nis passed along to git-clone under the hood. We already have ways to\npass through options like --single-branch for the same reason.\n\nAnd then presumably you could do:\n\n git submodule update --init -c core.sshCommand=whatever\n\nIn the meantime, as a workaround I suspect you could do it in two steps,\nlike:\n\n # set it for the initial clone; this is using the one-shot \"git -c\",\n # not \"clone -c\" that will actually save the result in the\n # new repo\n git -c core.sshCommand=whatever submodule update --init\n\n # and then save it for subsequent fetches\n git submodule foreach 'git config core.sshCommand whatever'\n\nIt's rather unwieldy. And I think gets weird if you want to cover only a\nsubset of paths, as it doesn't look like \"submodule foreach\" allows\nthat. So you might be stuck with:\n\n git -c core.sshCommand=whatever submodule update --init some-path\n git -C .git/modules/some-path config core.sshCommand whatever\n\nwhich is back to being overly intimate with the filesystem layout. There\nmight be a better way to do a per-module command. I don't really use\nsubmodules myself.\n\n-Peff\n"},{"id":"541529","messageId":"CAAC4ekoduJ03xjA08GouE_r9sJHnS4aTD3GgaA3GChdn6t_v8w@mail.gmail.com","threadId":"65474","inReplyTo":"20260414061558.GA2902306@coredump.intra.peff.net","subject":"Re: How should submodules use different sshCommand during initial update?","fromName":"Shibo Xia","fromEmail":"sbxia25@gmail.com","sentAt":"2026-04-14T07:25:41Z","receivedAt":"2026-04-14T07:25:55Z","isPatch":false,"body":"Thank you, this is very helpful.\n\nThe includeIf approach and the two-step workaround do seem workable, but\nthey still feel awkward when different submodules need different settings\nduring the initial clone.\n\nI would like to try a small RFC patch for this.\n\nMy current direction is a general per-submodule config injection mechanism\nfor submodule update --init, so that config can be passed to the underlying\nclone/fetch for one submodule without affecting others.\n\nDoes that sound like a reasonable direction for a first RFC patch?\n\nThanks,\nShibo Xia\n\nJeff King 于2026年4月14日周二 14:16写道：\n>\n> On Tue, Apr 14, 2026 at 09:28:20AM +0800, Shibo Xia wrote:\n>\n> > My concern is that this still solves the problem indirectly through URL\n> > rewriting / SSH host aliasing, rather than allowing the submodule's SSH\n> > behavior itself to be configured more directly.\n> >\n> > So I think this answers the practical \"how can this be done today?\" part,\n> > but I am still wondering whether there is a reason Git should not support a\n> > more direct per-submodule sshCommand-style configuration.\n>\n> For arbitrary per-submodule config, I can think of two approaches:\n>\n> One is conditional includeIf directives in your ~/.gitconfig, matching\n> based on the submodule names. Like:\n>\n> # replace PARENT and SUBMODULE with your filesystem names\n> [includeIf \"gitdir:**/PARENT/.git/modules/SUBMODULE\"]\n> path = .gitconfig-submodule\n>\n> and then in ~/.gitconfig-submodule, you'd have:\n>\n> [core]\n> sshCommand = whatever\n>\n> This works, but it's kind of gross, as it depends on the module naming\n> scheme (and isn't there a proposal to make these more opaque? I didn't\n> follow it). And of course you're not actually putting the config in the\n> submodule, but rather polluting your user-level config with it (which\n> might or might not be preferable, depending on what you're trying to\n> configure).\n>\n> The second thought is that we faced the same problem with \"git clone\"\n> itself: you might want to tweak some config after the repo is\n> initialized but before we fetch anything. We added the \"clone -c\" option\n> for that. It would seem reasonable to me to have a similar option that\n> is passed along to git-clone under the hood. We already have ways to\n> pass through options like --single-branch for the same reason.\n>\n> And then presumably you could do:\n>\n> git submodule update --init -c core.sshCommand=whatever\n>\n> In the meantime, as a workaround I suspect you could do it in two steps,\n> like:\n>\n> # set it for the initial clone; this is using the one-shot \"git -c\",\n> # not \"clone -c\" that will actually save the result in the\n> # new repo\n> git -c core.sshCommand=whatever submodule update --init\n>\n> # and then save it for subsequent fetches\n> git submodule foreach 'git config core.sshCommand whatever'\n>\n> It's rather unwieldy. And I think gets weird if you want to cover only a\n> subset of paths, as it doesn't look like \"submodule foreach\" allows\n> that. So you might be stuck with:\n>\n> git -c core.sshCommand=whatever submodule update --init some-path\n> git -C .git/modules/some-path config core.sshCommand whatever\n>\n> which is back to being overly intimate with the filesystem layout. There\n> might be a better way to do a per-module command. I don't really use\n> submodules myself.\n>\n> -Peff\n"}]}