There are many things about git submodules that are more unpleasant than they should be but one of the most frustrating is that you have to decide early whether to add the submodules as git+ssh URLs or https urls. If you pick ssh URLs, your Windows users using GUIs will not be able to check out the submodules. Whereas if you pick https URLs, your Mac and Linux users using the command line will not be able to check out the submodules. Once you have picked one of these choices, you can't change it
@ShadSterling@shironeko@mcc
I can tell you why I use it: it allows me to work on multiple different branches concurrently while having access to the other ones without having to switch every time, and without any useless duplication. It's particularly useful when some of the branches need to be developed in parallel or with frequent exchange/syncs because you can do it without any intermediate fetch step since the repo is the same.
I've gotten some responses expressing surprise at my comment about https submodules not working on Mac/Linux. A better way of putting it would be "Whereas if you pick on https URLs, it will appear at first to work, but then subtly and sometimes catastrophically break in special cases or when you try to perform certain actions, such as setting a github repo as 'private' or attempting to push back to a checked-out submodule, possibly weeks or months after you set the submodule up." Hope this helps
Unfortunately, in the process of fixing the problem it introduces new and vaguely horrific potential breakages, for example if you migrate a repository from bitbucket to github
@mcc "Whereas if you pick https URLs, your Mac and Linux users using the command line will not be able to check out the submodules. Once you have picked one of these choices, you can't change it" What?
Add comment