Tao of Git Submodules
Being a bloody webmaster has taught me a few hard lessons about git submodules.
The reason is that my CGI scripts managing the mailing lists and adding the navigation to the web pages proved to be quite reusable and I’ve moved them into their own git project. They are now used at at least 3 websites at the office as git submodules.
When Mr Noob first starts playing with them, usually this happens:
You have a project in ~/foo and another in ~/bar. Foo wants to reuse Bar as a subproject. So you call
$ cd foo $ git submodule add ~/bar
It’s all very nice. Until, as usual, your Foo project becomes very popular and the whole Galaxy starts clonig it. At this moment great panic of cosmic proportions breaks out, as they cannot obtain the Bar submodule’s files from
/home/Noob/bar
Of course not. You get it? The Tao of git submodules is this:
Think Big.
In other words specify a path to your submodule in a universal way. With a Universal Resource Locator.
The used protocol is also of extreme importance. It should allow unlimited read access for your entire target audience. For write-access they can always add another remote to the subproject later. If they get write-access at all.
/somewhere/in/your/filesystem
We have already discussed this.
Bad.
smb://
Some will have access, but most not. Samba is a LAN thingy. And it’s bloody slow.
Bad.
ssh://
It’s a URL, but it’s not universal enough, as your users won’t have access.
Bad.
http://
Put your subproject on a webserver, allow directory listing: universal read access obtained.
Good. If a bit slow with git.
git://
Guarantees universal read access too, and it’s fast as well.
Good. The only problem is some corporate proxies are watching port 9418 with raised eyebrows.
Bottom line: use the http:// or git:// protocols.
