Git submodules as single points of failure

I tend to avoid git submodules, not because I have very strong feelings about them, but mostly because I’ve tried to use and understand them, but continue to have problems. When faced with the option between learn more about git submodules and maybe it’ll work this time, and learn about a different way to incorporate git repositories, it’s just more compelling to choose the latter. However, there is one detail about submodules that I do believe is a true flaw.

When cloning a git repo, each submodule must be cloned recursively. Not only is this not done by default (it must be specified with the recursive flag), but it introduces single points of failure into the cloning process.

Imagine that you are building a project using Travis, and you depend on two other projects using submodules. If either of those projects’ repositories are unavailable for whatever reason (e.g. either host is unavailable, bad SSH keys, etc.), your build will fail. The more submodules you introduce into your project, the more chances you have to fail.

Why introduce single points of failure, when you can just check the third-party code into your own repository? This way, only a failure to clone the main repository will fail the build, which is strictly better than before. I’ve had good experiences using git subtree and git subrepo to manage dependencies in this way. And in addition to ensuring a more repeatable clone step between different machines, you’ll allow developers to use just the standard git commands to get up-and-running.