Re: [boost] [git] neglected aspects

Subject: Re: [boost] [git] neglected aspects
From: Tim Blechmann (tim_at_[hidden])
Date: 2012-02-09 06:07:44

> 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