Which remote should I use for git submodule?
I just recently come to a dilemma.
I whish to git submodule add to my repo, and the dilemma is this:
1. Should I make a fork of the repo and then add submodule of my own fork?
OR
2. Should I add submodule directly from remote?
What is the most usual scenario and how do other coders decide this?
Btw. I do not plan to modify code in submodules, my only goal is to use the library.
What ever is the usual ( or normal ), there seems to be an issue fetching remote when that remote is from another git provider, for example my repo is on github, and the submodule I which to add is on GitLab, and this probably is the reason for:
git@gitlab.com: Permission denied (publickey).
fatal: Could not read from remote repository.
I don't seem to have this issue with submodules on github, so the question is, what is normal and also how to deal with this issue?
**EDIT:**
OK, I figured out I needed to add a new SSH key to GitLab to be able to clone, however my question remains on whether the remote should by my fork or upstream?
I whish to git submodule add to my repo, and the dilemma is this:
1. Should I make a fork of the repo and then add submodule of my own fork?
OR
2. Should I add submodule directly from remote?
What is the most usual scenario and how do other coders decide this?
Btw. I do not plan to modify code in submodules, my only goal is to use the library.
What ever is the usual ( or normal ), there seems to be an issue fetching remote when that remote is from another git provider, for example my repo is on github, and the submodule I which to add is on GitLab, and this probably is the reason for:
git@gitlab.com: Permission denied (publickey).
fatal: Could not read from remote repository.
I don't seem to have this issue with submodules on github, so the question is, what is normal and also how to deal with this issue?
**EDIT:**
OK, I figured out I needed to add a new SSH key to GitLab to be able to clone, however my question remains on whether the remote should by my fork or upstream?
Last edited on
I don't think you need to fork the repository that you want to use as a sub-module.
To my understanding, Git remembers the specific commit (hash) of the other repository that you are "embedding" as a sub-module. So, you will stick with that specific commit of the sub-repository forever, even if there are new commits in the upstream (remote) repository.
This ensures that your code will not break unexpectedly, because of upstream changes.
You need to perform an explicit git submodule update --remote, in order to update your sub-module to the latest upstream commit.
To my understanding, Git remembers the specific commit (hash) of the other repository that you are "embedding" as a sub-module. So, you will stick with that specific commit of the sub-repository forever, even if there are new commits in the upstream (remote) repository.
This ensures that your code will not break unexpectedly, because of upstream changes.
You need to perform an explicit git submodule update --remote, in order to update your sub-module to the latest upstream commit.
Last edited on
There is one another possible issue that come to my mind.
Suppose you're working on a project which depends on 3rd party library which you use as a submodule.
The library owner at some point makes his repo private or it may delete it.
What happens is that you lose access to code.
This cannot be the case if you submodule it to your own fork.
It's unlikely that such thing would happen but if it does then what?...
Suppose you're working on a project which depends on 3rd party library which you use as a submodule.
The library owner at some point makes his repo private or it may delete it.
What happens is that you lose access to code.
This cannot be the case if you submodule it to your own fork.
It's unlikely that such thing would happen but if it does then what?...
The good thing with Git is, that you always have the full history in your local clone of the reop.
So, if the remote repo ever goes away unexpectedly, as long as you still have a local clone somewhere, you don't loose anything 😊
And you still could "push" your local clone to GitHub, GitLab, or whatever Git hoster you prefer, to create a new mirror...
So, if the remote repo ever goes away unexpectedly, as long as you still have a local clone somewhere, you don't loose anything 😊
And you still could "push" your local clone to GitHub, GitLab, or whatever Git hoster you prefer, to create a new mirror...
Last edited on
but submodule code is not in your git history, the only thing that is in history is remote url.
submodules have their own, separate history within submodule folder.
the only way to keep the code is to either fork it (for online storage) or download it for local storage, or both.
I suppose you mean that local submodule code would stay in your local repo, orphaned from remote.
submodules have their own, separate history within submodule folder.
the only way to keep the code is to either fork it (for online storage) or download it for local storage, or both.
I suppose you mean that local submodule code would stay in your local repo, orphaned from remote.
Last edited on
If your local Git repo contains a sub-module, and provided that the sub-module was initialized once, then the "sub-module" directory, inside of your "main" repo directory, essentially is a fully-fledged local clone of the remote/upstream repository, including full history.
(After all, a "sub-module" directory is just a normal Git repository, only located inside of another one)
So, when working with sub-modules, you will "automatically" have a clone of the remote/upstream repo(s) that you are using as sub-module(s). This you could always "push" to a Git server to create a new mirror, in case that the original remote repo vanishes...
(After all, a "sub-module" directory is just a normal Git repository, only located inside of another one)
So, when working with sub-modules, you will "automatically" have a clone of the remote/upstream repo(s) that you are using as sub-module(s). This you could always "push" to a Git server to create a new mirror, in case that the original remote repo vanishes...
Last edited on
Topic archived. No new replies allowed.