Re: [boost] [modularization] Modularizing Boost (modularization)

Subject: Re: [boost] [modularization] Modularizing Boost (modularization)
From: Ahmed Charles (acharles_at_[hidden])
Date: 2013-10-25 02:14:39

> Date: Fri, 18 Oct 2013 10:05:08 +0100
> From: daniel_at_[hidden]
> To: boost_at_[hidden]
> Subject: Re: [boost] [modularization] Modularizing Boost (modularization)
>
> >> which I think can be done while
> >> preserving history.
> >
> > How so? Replaying the history on top of master? That's still a loss of
> > history really, but it's better than a straight addition-of-current-version.
> 
> Possibly by including all the module history in each smaller module
> and, if possible, rewriting the history to only include the relevant
> headers (this would be done before the module is in use). This means
> there will be duplicate history in different modules, but I don't
> think that would cause any real problems. I admit I haven't thought
> this through or done any experiments, I was leaving that for later.
> 

Examining and modifying git repo history is something I've done quite a few times now and will end up continuing to do in the future. The primary issue in the case of boost would be making sure that the super-module references are still valid for anyone looking at history (i.e. you don't want to change every hash in the submodule and make the super-module invalid). I'd say that given the sizes of the individual git repos for the libraries in boost, that keeping the entire history in each of the split libraries would be feasible and not cost much at all.

It's useful to note that the entire git history for boost with an entire working directory with the latest boost code is smaller than an svn trunk checkout. So, overall, I'm not sure why losing history would ever be a discussion point given that keeping it costs so little.