Question:
Is there a way to automatically checkout git submodules via the same method (ssh or https) as the main repository?
Background:
We have a non-public gitlab repository (main
) that has a submodule (utils
) which is also hosted as a non-public gitlab repository on the same server. Those repositories can be accessed either via ssh or https:
[email protected]:my/path/repo.git
https://gitlabserver.com/my/path/repo.git
Both variants obviously require different forms of authentication and depending on the client computer and the user, one or the other is preferred.
For the top level repository (main
) that is not an issue, as anyone can choose the method he or she prefers, but for the sub module this depends on the .gitmodules
file and hence is (initially) the same for all.
Now instead of everyone having to adapt the .gitmodules file to whatever they prefer and make sure they don't accidentally commit those changes, it would be nice, if there was a way to just specify the server and repo path and git chooses either the same method that is used for the main repo, or something that can be set in gitconfig.
I finally solved this problem by specifying the submodules url as a relative path:
So lets say your main git repository can be reached
https://gitlabserver.com/my/path/main.git
[email protected]:my/path/main.git
And the .gitmodules
file looks like this:
[submodule "utils"]
path = libs/utils
url = https://gitlabserver.com/my/path/utils.git
That would mean that even when you check out the main application via ssh, the submodule utils would still be accessed via https.
However, you can replace the absolute path with a relative one like this:
[submodule "utils"]
path = libs/utils
url = ../utils.git
and from now on use
git clone --recursive https://gitlabserver.com/my/path/main.git
git clone --recursive [email protected]:my/path/main.git
to get the whole repository structure which ever way you want. Obviously that doesn't work for cases where the relative ssh and the https paths are not the same, but at least for gitlab hosted repositories this is the case.
This is also handy if you (for whatever reason) mirror your repository structure at two different remote sites.