Git submodules should have public remotes
If you include submodules into your git repositories, you should make them public if you expect others to use your project. If you use git@ references to these remotes, the person would need to have access to these too.
Example:
If your dotfiles should be sharable, include your remotes like this, with http access:
[submodule "vim"]
path = vim
url = http://github.com/<username>/dot_vim.gitThen anybody wanting to check out your repo and all children, could conveniently do this after her/his clone:
git submodule update --init --recursiveAnd all children are fetched recursively with all the submodule repos in one command!
Written by @kjellski
Related protips
2 Responses
I have a team that works with private repos and private submodule, the only thing that is required is that every one involved with the module has access to the submodule.
Yes, that's for sure! And if that is the case, just ignore the notes above. I've just not thought about that when I've open sourced some piece of code that had submodules and needed to update the .gitmodules files to enable others to conveniently use the public ones.
I just tried to point out that you might forget how deeply the submodules are nested and even the last one that is private would kill the "clone experience" :) for example:
.dotfiles # has mac-profile as submodule
mac-profile # has vim as submodule
vim
git submodule update --init --recursive # only works if anyone has
# access to all the recursive child refs
