One thing that submodules do better than subtrees is scale; in a subtree, everything is part of your repository (thus, index, and the associated problems with having having millions of files).<p>Submodules, on the other hand, have independent index files tied to independent repositories, so it's possible to not have a huge index anywhere regardless of total repository size.
Subtree makes the most sense when you have a component that is completely dominated by its parent, but which you want to also release stand-alone. For example, we use it for a build system that gets 90% of its use and testing (and essentially all its development) from one parent project, but is used in a few other much smaller projects.<p>Submodules provide weaker coupling and make the most sense when the submodule has its own healthy upstream and you want to track those versions. It's awkward if all submodule development is happening from within the parent.<p>My rule of thumb: If the sub-project has a test suite that is complete enough you can trust it, then use submodules or a different installation method. If the sub-project always needs the parent (preferably only one parent) to verify correctness, such that you prefer to make commits from the parent repository, use subtree.
I introduced git at $DAY_JOB roughly 2 years ago and based it on submodules. We use the submodule subscription feature of Gerrit to lessen the pain [1]. So submodules are not <i>that</i> bad but I really believe they are trying to solve a problem better solved by a dependency management system (maven and similar) instead.<p>So even subtree might be "easier" you should really try to solve your dependency problem using a resolver instead of your version control system.<p>[1] <a href="https://gerrit-review.googlesource.com/Documentation/user-submodules.html" rel="nofollow">https://gerrit-review.googlesource.com/Documentation/user-su...</a>
I've migrated all my project submodules to subtree after a number of frustrations, culminating in finding out that Heroku doesn't support submodules. But it's still a huge pain to actually push changes upstream.<p>Not counting the issues of submodule support by services that interact directly with Git repos, I think the big question is how often do you need to hit the upstream repo for pulls/pushes. If the answer is "not super often", subtree is probably lower maintenance. I think submodules are a little bit more natural in cases when you are making a lot of changes to the subrepo, particularly when it's more standalone. But even then, subtree is probably worth the extra bit of effort.<p>Actually, in cases when the coupling is very loose, I forgo both options and just check out the subrepo directly into the superrepo, and rely on .gitignore in the superrepo to keep them seperated.<p>At the end of the day, I think there really needs to be another strategy, and it would be great if there were a way it could be implemented in to the Git core. The concept of a modular project just doesn't seem to completely jive with the Git architecture. Anyone have any ideas how this could work?
> There are several reasons why you might find subtree better to use:<p>> subtree does not add new metadata files like submodules doe (i.e. .gitmodule).<p>So instead you have to memorize the exact information that in the .gitmodule file and type it in every time you run "git subtree" and then out of band communicate this information to your colleagues.
I've used this method:<p><a href="http://jasonkarns.com/blog/merge-two-git-repositories-into-one/" rel="nofollow">http://jasonkarns.com/blog/merge-two-git-repositories-into-o...</a><p>... in order to manage a communication protocol library specific to two programs. Originally there was three repos (Program A, Program B and the library), that I merged into a single repository. I can merge changes from the older repositories, that are still active.<p>It looks that this method is a close ancestor of git-subtree.
I would like to point out/plug an alternative to hg subrepos:<p><a href="http://mercurial.selenic.com/wiki/GuestrepoExtension" rel="nofollow">http://mercurial.selenic.com/wiki/GuestrepoExtension</a><p>I was part of the team that came up with it and I am inordinately proud of it. :-)