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

Subject: Re: [boost] Getting Started with Modular Boost Library Maintenance
From: Cox, Michael (mhcox_at_[hidden])
Date: 2013-12-26 07:03:14

On Wed, Dec 25, 2013 at 2:04 PM, Bjørn Roald <bjorn_at_[hidden]> wrote:

> 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?

>From the git-merge man page description of the --no-ff option (see below).

>
>  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?
>

Since all the commits that are on master are commits that were fast
forwarded from develop on a previous merge and any future commits on
develop will be successful merges from topic branches onto those same
commits, everything should fast forward merge onto master.  All
conflicts/merge resolutions should occur on the topic branches via rebasing
the develop branch onto the topic branch.  Once the conflicts are resolved
on the topic branch and the commits on it are split/squashed as desired
(see git-rebase INTERACTIVE MODE section), the merge to develop should be
clean and a --no-ff to ensure a merge commit is added to the develop
branch.  Merges from develop to master don't need the --no-ff because you
only merge to master on an official release of Boost which should be
tagged.  Also if you make an annotated tag of the develop branch before
merging into master, you will get the merge commit by default (see the last
sentence of the --no-ff option description below).

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.
>

You don't need the --no-ff to have "the develop branch be the head of a
sequence of commits where each commit represents a logical change to the
system".  The interactive rebasing of the topic branch should give you
that.  Most topic branches can be restructured into a couple of commits,
e.g. one commit for library code changes and one commit for modified/new
tests or if you really don't care how you got to the end result, you can
use a --squash commit to compress it into one commit.

> 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.

I think your confusing the merge option --no-ff with the --squash option.

> 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.

Agreed.

>
>
>  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.

I'm not sure I follow the part about the nits.  As far as hot fixes go (or
any type of topic branch for that matter), the same process is followed:

   1. The developer continually rebases other peoples changes onto the
   topic branch while working on the changes to implement the hotfix, feature,
   etc.
   2. The topic branch cleanly builds and passes all tests.
   3. Optionally the developer interactively rebases to structure the
   commits to a small number of logical commits, or if that's not important,
   --squash merges it into 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.
>
>
Exactly!

But if you run "git branch --contains master" in all the repository, it
will tell you that the HEAD commit of master is not in develop (since it
only prints out master).  And the way SHA1s work (i.e. the entire history
of that HEAD commit is encoded in it's SHA1), that means git thinks
*none*of the commits in master are in develop.  Note, even if you can
find a
commit that has the exact same comment with the exact same changes in both
master and develop, but the SHA1 is different, then git considers that a
different commit.

>  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.

I am advocating git-flow workflow.  I'm just telling you the git commands
your using don't look like they properly implement it. The changes should *fast
forward* flow from topic branches to develop to master.

>
>  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.
>

>From the Modular Boost Library Workflow
Overview<https://svn.boost.org/trac/boost/wiki/StartModWorkflow>,
the use of the develop branch doesn't sound optional.  Also from Peter's
proposal <http://thread.gmane.org/gmane.comp.lib.boost.devel/247192> it
doesn't sound optional.

Michael

P.S.  I think that the problem that git doesn't think all the commits in
develop are not in master may be because the way the conversion from svn
was done (or at least the way I understand it was done).  My understanding
is that the revisions on develop were created from the trunk and the
revisions on master were created from the {tags,branches}/release/*
revisions.  If that's the case, I'm not sure you can ever get git to think
all of the master commits are in develop.  The master branches have to be
linearized versions of all the svn revisions from trunk,
{tags,branches}/release/* in (probably) revision number sequence and then
just create develop from a "git checkout -b develop master".  This way
master an develop are identical.