Automatically access git submodules via ssh or https

Question

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.

Answer 1

I finally solved this problem by specifying the submodules url as a relative path:

So lets say your main git repository can be reached

• either via https://gitlabserver.com/my/path/main.git
• or via [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

• either git clone --recursive https://gitlabserver.com/my/path/main.git
• or 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.