I have a primary development machine, where I work on a project stored in GitLab repository. This project references submodules at some repositories. I also have a secondary sandbox machine that can't access these repositories. To make these machines in sync, I'm going to create mirrors of all necessary repositories on the secondary machine (I can access them from my primary machine). For the parent project, setting GitLab repository as upstream and mirror as origin on the primary machine and syncing between two of them and a local copy seems to be a solution. But how about submodules? I want primary machine repo to link to normal submodule repos, as it is on upstream from GitLab, and secondary machine use mirrored repos. And whenever I change a submodule revision in upstream (to commit these changes to GitLab), I also want mirrors to become in sync, and parent mirror on the secondary correctly referencing new revisions at submodule mirrors. How do I do that? What is the most clever way to set up things?
Syncing forked repository with forked submodules and original repository with original submodules
Viewed 191
1 Answers
TL;DR
You can use a relative URL for your submodule.
Details
When you use relative URLs, Git will look for the submodule on the same server as the main repo, in the same user space.
For example:
url = ../submodule.git
If you migrate the main repo to a new server, your submodules will automatically come from the new server.
If you work on a fork of the main repo, the submodules will automatically come from the fork space (so you'd need to fork the submodules too).
If you work on a clone somewhere else, same story, it all comes from that clone.
In all cases, push/fetch/pull all connect consistently to the same server and space as the main repo.
For my project, this really mattered to me when I maintained two active mirrors on two isolated networks: I didn't have to adjust anything in the submodule configuration between the two networks.
Related