pc95hg
Last Updated: February 25, 2016
·
802
· kjellski

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.git

Then anybody wanting to check out your repo and all children, could conveniently do this after her/his clone:

git submodule update --init --recursive

And all children are fetched recursively with all the submodule repos in one command!

2 Responses
Add your response

7300

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.

over 1 year ago ·
7304

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
over 1 year ago ·