What happens when a GIT submodule goes 'offline'?
I”m still trying to figure my way out around GIT submodules. Let’s say I’m using submodules pointing to a public repository to which I only have read access.
What happens to my project when that repository is taken offline and no longer accessible?
3 Solutions collect form web for “What happens when a GIT submodule goes 'offline'?”
That’s one of the beauties of git/DSCM: your local clone is a complete standing repository. Submodules are no exception.
Any “central” repository is simply a location where developers of a project
agree to push changes to. Write access in simplest terms means that you get to push to this pre-agreed upon location. Theoretically you could even network multiple “central” repo hosts and have developers push to each one, or have each repo run hooks to sync with each other.
Because every clone of a git repository (including submodules) is a complete repo by itself, if that central official push location gets changed, or disappears you still have a completely working repository with full read/write access to your local clone.
In the case that the official submodule project developers decide that they simply wanted to relocate their “central” clone, all you have to do is update your submodule’s remotes to point to the new, correct location.
GitHug: Adding a remote
GitBook: Remote Branches
GitBook: working with Remotes
Suppose that your project can be accessed by other people. This implicitly means that these user would also need access to any submodules your project uses.
You could re-host your local submodules (known as “forks”) and modify your main project repo to refer to the forked repos. This is preferred over copy/paste, and may be a good idea even if the official repo is still around. This is dependent upon the license the original project was provided under, of course.
Few reasons why this is a good idea:
- You can make changes to your fork without having been granted write access to the
- If the official central repo goes dark, you still have a complete live version for anyone who wants to check out your project.
- Unlike the copy/paste version, it’s relatively easy to keep a forked repo in sync with the official repo. Plus, you get to keep all of the branches and history of the original repo, where-as with copy/paste you just get an initial copy commit history item.
- The submodule repo maintainers may decide to incorporate some of your changes back into the “official” version. Again, relatively easy to do if they have a complete repo clone to work with (which a submodule is).
In a way submodules are are viewed as separate repositories. So if your submodule repo goes offline – there is no way to update a submodule.
When you use a submodule you imply that the repo is accessible to all the developers throughout dev cycle.
Only use submodules for relatively stable components.
Your repository is yours, you still have everything you did before. If you can find another source for the project, just change the URL. What’s in
.gitmodules is administrative assistance at managing the distribution, nothing says you have to use the suggested URL. Your repo uses what’s in
git submodule just loads the defaults.