Subject: Re: [boost] [git help] Documenting common modular boost workflows
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-10-22 22:45:59
on Mon Oct 21 2013, Beman Dawes <bdawes-AT-acm.org> wrote:
> On Mon, Oct 21, 2013 at 10:15 AM, Peter Dimov <lists_at_[hidden]> wrote:
>> Dave Abrahams wrote:
>>> IIUC we already agreed long ago to use gitflow:
> Yes, but how do Boost developers and release managers "use gitflow" ?
See my reply to Peter.
>> It's not entirely clear to me what using gitflow would mean in the context
>> of a Boost superproject with per-library submodules. Who is "we" who would
>> be using gitflow, the Boost release managers or the library maintainers?
>> When Boost release 1.64.0 is started, who is going to create the gitflow
>> release branch, and from what?
> Yes, those are exactly the sort of questions I had in mind. Sorry for not
> being more explicit. Let me try again:
> 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?
I don't understand the source of mystery here. This is bog-standard Git
git checkout develop
# make edits
git push origin develop
[I'm not going to translate to TortoiseGit/other]
> 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?
> 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?
In gitflow, merging into master means creating a release. See
http://nvie.com/posts/a-successful-git-branching-model/ starting with
"Creating a release branch" and ending at "Hotfix branches" for the raw
git commands. But those are complex. Just install gitflow and
git flow release start v<version_number>
git flow release finish v<version_number>
As you can see, that's a lot simpler. I strongly recommend using the
gitflow tool because it will save lots of trouble and prevent mistakes.
[I just found http://danielkummer.github.io/git-flow-cheatsheet/ which is
a really good guide.]
-- Dave Abrahams
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk