I am interested in your views here. I have had good success with git and monolithic projects. How would you go about working on your library and then pushing to the central repo. Would you envision that the central repo is nothing more than a shell pointing to submodules that are the "real" library repos?
the semantics of git submodules is a bit weird: if you check out a new revision of the top-level repository, the submodules won't be updated automatically, but you need to run `git submodules update' manually ... i am using submodules for tracking some external dependencies and in my experience 70% of the compile failures of my users are related to submodules getting out of sync. for a project like boost, i'd therefore suggest to avoid submodules. the advantage however is that the full git repository of boost is few hundred mb ...
Or would you just rebase all of boost before committing back modifications to your library? Or some other process completely?
if changes are trivial, i usually rebase to the current master before pushing new changes to the public repository. the reason is mainly to avoid unnecessary merge commits in the history. if changes get too complex, merging is usually better ... also more friendly for bisecting bugs.
I'm sure people have thought about this problem and the solutions. You might be one of them. Unfortunately I mostly hear how great it would be to move to git but few have provided the usage for a project like boost
: a loosely coupled and independently developed collection of libraries.
well, just because git provides some features, we do not necessarily have to use them ... it can be used in a similar manner to the current svn repository, only managing two branches cheers, tim