Re: [boost] question/guidence regarding merge to master

Subject: Re: [boost] question/guidence regarding merge to master
From: James E. King III (jking_at_[hidden])
Date: 2019-01-11 13:04:45

On Thu, Jan 10, 2019 at 9:20 PM Robert Ramey via Boost <
boost_at_[hidden]> wrote:

> I'm looking to merge my develop branch into the master so that they will
> be in sync.  I'm thinking that this the changed in develop should be
> squashed so that the master branch doesn't included all the the
> intermediate changes made during the develop phase.  Is there any boost
> rule/practice/guidence regarding this?.  Ideally, I'd like to see the
> master have only one set of consolidated changes for each release.  But
> I'm not the person who decides these things or does the work.  Any
> insight by other parties would be appreciated.
>
> Robert Ramey
>
>
Any merge from master into develop should be empty (i.e. nothing to do).
This ensures you didn't miss anything in the past through a bad procedure.
(for example someone checking into master directly, which I've seen)

Any merge from develop into master should always be a fast-forward.
If you squash commits when going from develop to master, you cannot
prove that develop is missing anything from master because you cannot
merge master into develop.

I had to do this and fix up the missing/conflicts on all the CMT
repositories.
I'd also recommend if you have more branches lying around than develop
and master that you consider removing them unless they are for active
team development of a feature.  Otherwise you should be using a fork and
using your own travis and appveyor accounts to prep your changes so that
you do not consume Boost CI resources.

My recommendation is that your commits to develop are considered project
history and they do not get rewritten by rebase or squash into master, and
certainly never by a force push.

Pull requests run the same CI as a push does, so you should be able to get
CI stable on your PR before you rebase your PR into develop.  Then you
can always merge (fast-forward) develop into master.

I don't see any benefit in consolidating all the changes in master to one
commit.  You can accumulate all the changes using git by comparing the
tags between releases.  Further nobody who consumes boost from a release
sees any of this stuff anyway.

If you want to fix your branches, do this:

1. git clone your-repo
2. git checkout -t origin/develop
3. git merge master

If you have any commits in master not in develop, this will pick them up.

4. git push
5. git checkout master
6. git merge develop

This merge should be a fast-forward because of what you did in 3.

What you proposed by squashing commits into master would cause
us to have to force push a new consolidated commit into master during
the release cycle, which would rewrite history, which is bad for everyone.

- Jim