I have a workflow where I need to be able to pull several repos from one git server (server1) and push to another git server (server2). server2 resides on a network without Internet access, and some repos use submodules which refer to other repos that reside on server1.
Normally when I clone the super-repo (the one containing submodules) recursively, it clones the submodules from their original source. However, that is not an option when cloning from server2, because server2 does not have Internet access.
My thought was to push the submodules onto server2 and have those versions cloned when cloning the super-repo from server2. How do I achieve this while preserving the ability?
i.e., assuming all repos on server2 are identical to those on server1, I want the following 2 commands to be equivalent even though a build machine on server2's network cannot reach server1 to recursively clone the submodules:
git clone --recurse-submodules https://server1/super-repo.git
git clone --recurse-submodules https://server2/super-repo.git (and recall that server2 cannot reach server1 when recursively cloning submodules)
I was thinking of trying to achieve this through branches but that seems like it will introduce a maintenance issue.
Maybe, in your case it worth trying to do the following.
Git stores information about submodules in the following location: <root project folder>/.git/modules/<folder with name of your submodule>config
.
Config file should have section
[remote "origin"]
url = <url to your submodule>
Thus, maybe you could use some bash script, which will override this setting on the server2
, and afterwards - close submodule. But then, if has to change it back, so after next pull from server1, there will be no conflicts.
Also, there is .gitmodules
file in root folder of the project, which contains the same - information about url to submodules. Maybe, it is enough just to modify this file, and then during clone it'll reference to new submodule url. But, in this case, modification of this file will be considered as change for git, b/c this file is under source control.
Another alternative, is to have local git server, which will be available for server2
and server1
through local network. Then, it can contain fork of submodules from network server, but server1
and server2
will nicely get submodules update from it...
I ended up changing my submodule URLs to relative URLs, and on my development machine that fixed it. I'll try deploying this solution at work tomorrow.
A drawback that I encountered is that the submodule repos have different names on server2 due to a new naming convention that is being enforced, meaning the relative name on server1 does not match the relative name on server2. I am going to get around this by renaming the repos on server1.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With