On Mon, Oct 21, 2013 at 8:11 PM, Niall Douglas
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).
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 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.
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 super-module?
I think the hard part there is who admin's that process.
The admins for the super-project are the boost release managers. --Beman