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/