Boost logo

Boost :

Subject: Re: [boost] [git help] Documenting common modular boost workflows
From: Beman Dawes (bdawes_at_[hidden])
Date: 2013-10-21 21:18:27

On Mon, Oct 21, 2013 at 8:11 PM, Niall Douglas <s_sourceforge_at_[hidden]>wrote:

> On 21 Oct 2013 at 12:28, Beman Dawes wrote:
> > 1) What git/TortoiseGit/other commands would a Boost library maintainer
> > have to execute if, after following
> >, they wish to fix a
> > simple bug in their "develop" branch?
> TortoiseGit hides "gitness" from the user by often executing more
> than one git command than is obvious. Hardcore git users get upset by
> this, but I personally don't mind except when command line git
> doesn't do what I expect because I've become too used to TortoiseGit
> (e.g. changing a file while editing a commit message commits the
> changes on TortoiseGit, but does not on command line).

Some developers will prefer GitFlow. Others will use the command line. And
still others with use other tools. We have to support all of them with at
least minimal documentation.

> > For that matter, does a Boost library maintainer even start by
> > Is there a more
> > preferable approach?
> That page basically clones and checks out a kitchen sink Boost with
> all possible git submodules. That rather makes modularisation
> pointless.
> What we really need is for each Boost module to specify its
> dependency Boost modules, and that way only the git submodules needed
> are cloned. Therefore if I want to use Boost.AFIO in my project, AFIO
> will specify it needs Thread and ASIO and those get git submodule
> update --init --recursive.

Maybe someday, but not now.

> > 2) What git/TortoiseGit/other commands would a Boost library maintainer
> > have to execute if, after (1) they wanted to merge it into their
> library's
> > "master' branch?
> I think the only sane way is to have the master Boost master repo
> track which SHA in a submodule's master branch is the sanctified
> known true stable incarnation of the library. A library can commit
> what they like to whatever branch - and we can't stop them. But we
> can gatekeep which SHA in that repo is considered valid by master
> Boost master.

Un, didn't you just describe how a git sub-module works?

> We do indeed need a process for automating that, unless you want to
> give write access to the master Boost master repo to all Boost
> authors (I assume you don't!).

Wouldn't the sub-module developer just send a pull request to the

> I think the hard part there is who
> admin's that process.

The admins for the super-project are the boost release managers.


Boost list run by bdawes at, gregod at, cpdaniel at, john at