Git submodule support

[rgalonso]

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.

[mafredri]

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:

.devcontainer/devcontainer.json:

{
	"initializeCommand": ".devcontainer/initialize.sh"
}

.devcontainer/initialize.sh:

#!/bin/sh

git submodule update --init

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.

[rgalonso]

@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
    ├── Dockerfile
    ├── devcontainer.json
    └── submod
        └── install.sh

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.