
on Mon Oct 21 2013, Beman Dawes
On Mon, Oct 21, 2013 at 10:15 AM, Peter Dimov
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