> There is a horrible habit of people forking
  > projects on github just so their submodule
  > stay stable. It's broken.

People are forking projects on github in that way because it's a quick, easy, cheap way to create a mirror/hosted copy of the repository they want to use.

I don't see how this is an example of how git-submodule is broken. If you want to use someone else's code, that is under someone else's control in your repository without creating your own backup of said code, then you're the one taking the risk by not creating said backup.

If the git-submodule is mission-critical to you then you should either:

1. Always keep a separate mirror of the 3rd party repo.

or

2. Mirror the 3rd party repo to a hosted location, so that your submodule can point to the mirror instead of the source (basically creating a caching layer under your control).

This is no different than the guy that keeps all of his email in Gmail, then complains because Google shut down his account that 'email is broken' because it's possible for this to happen.

Sure. Why I explained the work around. Subtree includes the full history of the other project without work-arounds

subtree also includes the full history of the other project in your project's history unless you squash all of the commits (and if you squash them, then you haven't stored the full history). There might also be licensing reasons for wanting to keep the repositories separate, but not.

Which is why you should only use submodules with repositories under your control. At my work we happily use git submodules. Much better than svn externals and much better than any alternative that existed so far.

>There is a horrible habit of people forking projects on github just so their submodule stay stable. It's broken.

Yes I do this and I hate doing it!