Re: [boost] Getting Started with Modular Boost Library Maintenance

Subject: Re: [boost] Getting Started with Modular Boost Library Maintenance
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2013-12-25 16:04:09

On 12/25/2013 08:52 PM, Cox, Michael wrote:
> After reading the thread "avoiding fast-forward merges" and looking at the
> latest https://svn.boost.org/trac/boost/wiki/StartModMaint, I'm getting
> totally confused on the boost git flow.  I thought  all the commits on the
> develop branch of all the repositories are fast forwarded onto their master
> branches.  Note, that the --no-ff still tries to fast forward the branch
> and adds a merge commit

No it does not, where did you get that from?

> if  the fast forward succeeded to "mark" the merge
> into master (not sure this is really necessary, since you should have a tag
> on that last fast forwarded commit

I do not follow this, sorry.

> The develop branch should *always*
> fast-forward,
> unless some history editing has occurred.

*always* fast-forward* -  Why?

The main idea of using --no-ff is to allow the develop branch to be the 
head of a sequence of commits where each commit represent a logical 
change to the system.

Feature branches in git-flow allow long running feature work to go on in 
a separate branch with separate sequence of commits.  When this work is 
ready to integrate into the develop branch, the feature branch 
developer(s) may leave the feature branch commits as is or clean it up 
before merge.  The effect of a successful merge of 
feature/my-new-feature into develop with --no-ff will be *exactly* one 
new commit in develop regardless of the number of commits in the feature 
branch.  The new commit will be titled "merge feature/my-new-feature" 
and the history of the work is in a separate fully merged branch.  The 
local branch ref can be disposed of and is not needed any more. It does 
not need to be pushed to the public repository.

> Here's the description of the
> fast forward options from the man page of git-merge.
>
>          --ff
>             When the merge resolves as a fast-forward, only update the branch
>             pointer, without creating a merge commit. This is the default
>             behavior.
>
>         --no-ff
>             Create a merge commit even when the merge resolves as a
>             fast-forward. This is the default behaviour when merging an
>             annotated (and possibly signed) tag.
>
>         --ff-only
>             Refuse to merge and exit with a non-zero status unless the
> current
>             HEAD is already up-to-date or the merge can be resolved as a
>             fast-forward.
>
> In fact, since we can't enforce fast forward merges on the server side on
> Github, The command line option should be --ff-only. That way if the merge
> fails, you know somehow a commit got on master that isn't on develop or
> maybe you have some stale branches you need to re-pull.

I am not saying this does not make sense, but I am sure there will be 
people having nits with the restrictions this policy imply as well. 
E.g. how do you handle hot fixes that are out of line with the commit 
sequence in develop.

> With the --no-ff
> option and a master that isn't in sync with develop, you'll just put a
> merge commit on master and not fast forward the development history from
> the develop branch onto master.

Well as one that have used git-flow for some time at work, this is not 
at all my general feel of things.  I am pretty sure you will end up with 
an identical tree in the master merge-commit as in the develop 
merged-from-commit in all but exceptional cases that I can think of may 
be caused by not following git flow-rules.  I expect git-flow tools to 
automate checking for this.  If you think of how change set actually 
flows in git-flow, there should not be anything in master that is not 
already in develop.  Also, it is *not* like you will merge to master 
very often.  You synchronize the work in develop if you use git-flow, 
not in master.

> If you're lucky, you might get some merge
> conflicts that will alert you to the problem.

I like to see evidence of these sorts of problems in real use of 
git-flow and assess real git behavior and alternative fixes before I 
will conclude that this is an important issue by any measure.  At least 
not important enough to not recomend git-flow as is.

If you feel like documenting and supporting alternative git work-flows 
for boost library authors, I am sure it will be welcomed.

> On the StartModMaint page, there is command line sequence:
>
>
> cd modular-boost
> git checkout master
> git pull
> git submodule update
>
> Shouldn't that be "git checkout develop"?

Maybe.  I guess that depends if you want the latest boost release or the 
latest in master from each library.

> Are we not using the develop
> branch at all?

For the boost supermodule I think it is where selection of and testing 
of submodule commit (release) candidates for next boost release will go 
on.

I think each library may use develop as they please, but for larger 
libraries with a team of developers, use of develop is recommended as 
part of the git-flow process.  Other work flows may be used as long as 
the master branch is reserved for releasable commits.

--
Bjørn