You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There doesn't appear to be a way to clone a repo with submodules. In my use case, the devcontainer is built up using files coming in from a submod, so this is critical.
It looks looks like support for this would need to be added to CloneRepoOptions in git.go. The underlying git-go options already support this, so hopefully this isn't a heavy lift. See CloneOptions.RecurseSubmodules in go-git/options.go.
Finding the above references is about the extent of my Go knowledge though, so I can't offer a patch myself.
Hey @rgalonso could you share a bit more about how your repositories are structured and where the devcontainer files are located?
I'm not sure whether or not we support it currently, but utilizing the devcontainer.json initialize command seems like it could be one solution to this issue:
That said, I do think it's a good idea to expand envbuilder with an GIT_CLONE_RECURSE_SUBMODULES=true option. The default behavior should be false so that we don't needlessly enable long checkout times for every project utilizing submodules.
devcontainer.json references a Dockerfile which in turn has a COPY command that references install.sh. install.sh is found in the Git submodule checked out at .devcontainer/submod.
Your suggestion to use initializeCommand may be a viable workaround. It's not ideal though, because VSCode is already properly handling the submod, so I wouldn't want to duplicate the effort.
Agreed that GIT_CLONE_RECURSE_SUBMODULES should default to false. No need to slow everyone down with unnecessary checkouts.
Activity
mafredri commentedon May 7, 2024
Hey @rgalonso could you share a bit more about how your repositories are structured and where the
devcontainerfiles are located?I'm not sure whether or not we support it currently, but utilizing the
devcontainer.jsoninitialize command seems like it could be one solution to this issue:.devcontainer/devcontainer.json:{ "initializeCommand": ".devcontainer/initialize.sh" }.devcontainer/initialize.sh:#!/bin/sh git submodule update --initThat said, I do think it's a good idea to expand
envbuilderwith anGIT_CLONE_RECURSE_SUBMODULES=trueoption. The default behavior should befalseso that we don't needlessly enable long checkout times for every project utilizing submodules.rgalonso commentedon Jul 8, 2024
@mafredri , sorry for the delay in replying but I haven't been working on this project recently. The repo is set up as follows:
devcontainer.jsonreferences aDockerfilewhich in turn has aCOPYcommand that referencesinstall.sh.install.shis found in the Git submodule checked out at.devcontainer/submod.Your suggestion to use
initializeCommandmay be a viable workaround. It's not ideal though, because VSCode is already properly handling the submod, so I wouldn't want to duplicate the effort.Agreed that
GIT_CLONE_RECURSE_SUBMODULESshould default tofalse. No need to slow everyone down with unnecessary checkouts.