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

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
usage:

cd my/submodule/directory
git checkout develop
# make edits
git commit
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?

Not today.

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