Submodule config results in mixed protocols after cloning

[ErisDS]

We're having some difficulty documenting the best way to setup the Ghost repo & submodules for contributing, as cloning the top-level repo results in a mix of https and ssl URLs in the git config for submodules.

What we want is for there to be a clear and minimal set of commands that result in a correctly setup environment. This environment should be optimised for contributing, not for installing Ghost - which should use the CLI.

The current setup is using https:

[submodule "content/themes/casper"]
	path = content/themes/casper
	url = https://github.com/TryGhost/Casper.git
[submodule "core/client"]
	path = core/client
	url = https://github.com/TryGhost/Ghost-Admin.git

Cloning works reliably this way, but when pushing, git checks all remotes and will prompt you for a password, meaning you need to do quite a lot to get all of the remotes setup correctly.

There appear to be 3 potential solutions:

Option 1. Use Git SSH

[submodule "content/themes/casper"]
	path = content/themes/casper
	url = git@github.com:TryGhost/Casper.git
[submodule "core/client"]
	path = core/client
	url = git@github.com:TryGhost/Ghost-Admin.git

Option 2. Full relative URLs

[submodule "content/themes/casper"]
	path = content/themes/casper
	url = ../Casper.git
[submodule "core/client"]
	path = core/client
	url = ../Ghost-Admin.git

Option 3. Urls relative to the TryGhost org

[submodule "content/themes/casper"]
	path = content/themes/casper
	url = ../../TryGhost/Casper.git
[submodule "core/client"]
	path = core/client
	url = ../../TryGhost/Ghost-Admin.git

Relative urls means git uses whatever protocol is used on the top level clone for all the submodules.

Using fully relative URLs would open the option to cloning a fork, and automatically having all of the right remotes setup. However, you'd have to have all 3 repos forked to start.

Using URLs relative to the TryGhost org means the top-level protocol is honoured for submodules, and git uses the upstream TryGhost remotes for submodules, meaning you still have to add remotes if you want to work on Ghost-Admin or Casper.

Using git urls means the protocol and remotes are all fixed to use TryGhost with git. This mechanism should be the easiest to reason about, as it should always do the same thing.

Conclusion

For now, I suggest option 1 (git urls) because I think consistency is more important than flexibility, however if we still have problems balancing having a clear path to contributing with weirdness with ports and git not working on certain systems, options 2 and 3 are available to try out as well.

[ErisDS]

OK that broke travis - trying option 3

Broken build: https://travis-ci.org/TryGhost/Ghost/jobs/466076267

git clone --depth=50 https://github.com/TryGhost/Ghost.git TryGhost/Ghost
cd TryGhost/Ghost
git fetch origin +refs/pull/10051/merge:
git checkout -qf FETCH_HEAD
git submodule update --init --recursive
Submodule 'content/themes/casper' (git@github.com:TryGhost/Casper.git) registered for path 'content/themes/casper'
Submodule 'core/client' (git@github.com:TryGhost/Ghost-Admin.git) registered for path 'core/client'
Cloning into '/home/travis/build/TryGhost/Ghost/content/themes/casper'...
Warning: Permanently added the RSA host key for IP address '192.30.253.113' to the list of known hosts.
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.

[randallb]

FYI this made my heroku push fail. I ended up switching to the HTTPS one and it seems fine now.