[boost] [git] avoiding fast-forward merges

Subject: [boost] [git] avoiding fast-forward merges
From: Peter A. Bigot (pab_at_[hidden])
Date: 2013-12-25 09:04:39

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 <daniel_at_[hidden]> 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.