on Thu Feb 09 2012, greened-AT-obbligato.org wrote:
Beren Minor <beren.minor+boost@gmail.com> writes:
On Thu, Feb 9, 2012 at 12:07 PM, Tim Blechmann <tim@klingt.org> wrote:
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 ...
Submodules are probably misunderstood and misused most of the time. I think it was not meant to be used to have separate repositories for sub-part of the projects and a everything evolving together in sync. I see the use of submodules more like integrators would do, retrieving specific revisions of various sub projects, and testing these versions alltogether. Whenever parts integrates well, the submodule versions that work fine together are frozen in a commit. This is not very usable if you try to develop directly in the "main" repository that has the submodules.
I think that's right.
For Boost, I would say it could be used and even a powerful tool for integrating libraries together, testing them and managing release lifecycle, but could hardly be used for day to day library development.
I would recommend using git-subtree. It's the submodule-like tool more appropriate for what boost is: a collection of project units that can be built and tested independently but also make sense as a cohesive whole.
git-subtree is getting integrated into the official git repository now and should be available in the next month or two. Of you you can always get it here:
I don't think git-subtree is the right tool for us. Suppose libraries A and B both depend on libraries C and D. It would IMO be a disaster if the repositories for A and B each included the source to C and D. -- Dave Abrahams BoostPro Computing http://www.boostpro.com