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-26 09:03:54

On 12/26/2013 01:03 PM, Cox, Michael wrote:
> 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).
>

I think that man page description can be improved, it is not very clear 
in the point that --no-ff means no fast-forward, but that is what it 
means.  It attempts to say that if the merge is a simple fast forward, 
It will instead make exactly one new commit.  Note that a fast forward 
involves no new commit, instead it just moves the ref to the branch head 
forward along the path of the branch you are merging into your checked 
out branch.  I recommend to test it.

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

I do not generate any internal heat on eighter way, I just recomend 
following what the git-flow actually say as that is well known and 
documented.

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

No I am not.

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

I am short on time and cant reply as I would want to, I think we should 
simply recommend something that are well understood, Unless someone 
steps up and are willing to support other recommended ways of using git.

I am probably going to be largely off-line the next 2 weeks, will try to 
check in from time to time.  I may reply to the rest later when I have 
read it.

Best regards
--
Bjørn