You have found the core issue with svn/git: svn allows you to have a large repo with everything (and atomic commits across it) and to have users check out parts of the repo separately. git does not, because the svn separate checkouts model only works with a remote repository that you don't keep a copy of. With git, cloning the repo gets you the whole thing. One thought is that you may want to separate how you organize boost sources in git and how you release them. It's possible to have a single git repo for all libraries and have atomic commits but then create distfiles for each library separately. git becomes a bit slow when repositories get really large (although other tools are not any better - the problem is in the sheer number of vnode ops necessary for the semantics). I have a repo with all of NetBSD's "src", "xsrc" and "pkgsrc" in it, and "git status" can take several seconds because it is calling stat on 230K files. With only 23K files, things should be ok. My advice (which is not really about git) is to figure out whether you want: A) a set of interrelated libraries on which you will allow atomic commits that change interfaces/usage in multiple libraries or B) a set of independent libaries which have commits to separate libraries, and for which you insist that each library have an API and ABI compatiblity story, so that even when upgraded other libraries can continue to use it. For A, you probably want one git repo, much as you have one svn repo now. For B, multiple git repos are the right answer.
Attachment:
pgpe52FZCAX3k.pgp
Description: PGP signature