[colin_mccabe]

The only downside he lists for git-subtree is that "your history will be complicated unnecessarily" if you use the rejoin option, and subtree pushes are slow if you don't use that option. But his solution also creates more than one commit whenever a change modifies a "subrepo" / library as well as the main codebase. So it doesn't really seem any better from the history point of view. Am I missing something?

[brechtm]

git-subtree duplicates history. First you make a regular commit containing both your main project's changes and the subtree changes. Afterwards the subtree change is merged in again (or "subtree split --rejoin" or "subtree merge").

The advantage of git-subrepo is that your changes are immediately split up between the main project and the subrepo. Eventually, you should also be able to supply a separate commit message for the subrepo change (see "random ideas" section in the article).