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

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.

Niall

-- 
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/