[boost] [git] avoiding fast-forward merges

Forked from Re: [boost] [git][multi_index] help merging from develop On 12/25/2013 06:03 AM, Daniel James wrote:

On 25 December 2013 11:57, Daniel James wrote:

...

You can, but you don't need "-s ours":

git checkout develop git merge master

It should be a fast-forward merge.

Oh sorry, I just remembered why I didn't suggest merging into develop. The recommended work flow is not to do fast forward merges in order to keep the two branches separate.

Is this (keeping the two branches separate) the right rationale? I take "separate" to mean having no commit (SHA1) that is present on both branches (other than, for new modules, an initial master/develop branch fork which serves as the first merge base). A fast-forward merge necessarily places the same commit on both branches. git-flow recommends avoiding fast-forward merges to branch develop so the historical feature branch is preserved and to bundle the merge effect into a single commit, simplifying reversion. But this is more of a per-module traceability policy in the selected workflow than something that has a material effect on overall Boost process. In contrast, for Boost modules it's important not to do fast-forward merges to master, because a maintenance plan or email somewhere said super-project release managers may choose to select an earlier version on a module master branch to resolve integration failures.[*] To achieve that it must be possible for the manager to identify stable releases on the master branch, which would not be the case if a fast-forward merge added a commit series that did not stabilize until the final commit. The simplest derived requirement is that every commit on the master branch must represent a stable module, enforced by --no-ff. This I understood to be a strict requirement for the module master branch regardless of the module maintainers' chosen workflow within the module, but it does not affect workflow for develop. The effect of adopting these two practices may be that develop and master are kept separate. But that's not necessarily true if the develop branch itself is always kept at a releasable state, or if I misconstrued the strict requirement that stable release points on the module master branch be recognizable. If only master HEAD must be kept releasable the simplest work flow is to do a fast-forward merge from develop to master and push the results at any time where develop is considered stable enough to release. If there's an another rationale for keeping the branches separate I'd like to hear it to better my understanding of how git is expected to be used in Boost. Peter [*] I can't find the super-project release plan text about selecting non-HEAD module master branch contents from which this requirement is derived. https://svn.boost.org/trac/boost/wiki/ModBigPicture has a more lax requirement that pushes to master only be done when the content is stable, which will work in the more common case where there are no interoperability issues. The strict requirement makes sense, though, and I'm sure I read it somewhere.