Re: [boost] [git help] Documenting common modular boost workflows

Subject: Re: [boost] [git help] Documenting common modular boost workflows
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-10-21 20:11:32

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
> https://svn.boost.org/trac/boost/wiki/TryModBoost, 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).

> For that matter, does a Boost library maintainer even start by
> https://svn.boost.org/trac/boost/wiki/TryModBoost? 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.

> 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.

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!). I think the hard part there is who 
admin's that process.

Niall

-- 
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/