Boost logo

Boost :

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

On 21 Oct 2013 at 17:15, Peter Dimov wrote:

> Dave Abrahams wrote:
> > IIUC we already agreed long ago to use gitflow:
> 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?

I should firstly stress that I think people are confusing git flow as
a process and git flow as the tool which you install into git.

The latter simply is a script which implements the former of course,
but I'll be frank in saying I think it is too toy for useful use in
modularised Boost. An elaboration of that tool could be just fine,
and I think that's what Beman is asking: for a set of canned git
command sequences, preferably with TortoiseGit equivalents, for
various common operations.

The former, git flow as a process, I think for a single repo is
totally uncontroversial. It's how I and anyone else I know would
naturally use Git once you're used to it. For modularised Boost, git
flow as a process needs extending to cope with how we've done
modules, because how we've done modules I think is fairly unique.

I think that topic - how do we extend git flow the process to cope
with Boost modularisation - is where we should be focusing our
attention, not on git flow the tool, git flow the process for a
single repo, whether we agreed on git flow, whether git flow is good
or bad etc.

Once agreed, then we know how to extend git flow the tool usefully.
And possibly TortoiseGit too.


Currently unemployed and looking for work.
Work Portfolio:

Boost list run by bdawes at, gregod at, cpdaniel at, john at