Why are there code changes in the brznch in the first place?

Sent from mobile device, please ignore spelling mistakes.
________________________________
Von: James E. King III
Gesendet: 08.01.2019 16:33
An: dev@thrift.apache.org
Betreff: Branch history fixups

Our release branching strategy has left a number of loose ends.
Specifically, none of the release branches except for 0.12.0 have been
merged back into master.  Based on the way past releases were done, we
would branch off master then make a number of versioning changes which were
never intended to be merged back.  Without merging back, this leaves the
possibility that one could strand an important code change in a release
branch. It also leaves master with incomplete history.  In this type of
merge one does a "git merge --strategy-option=ours origin/<branch>" and
drops any collisions against master.

I'm going to start doing this for our release branches, ensuring the
resulting differences are negligible.  This will ensure we haven't missed
anything along the way, and GibHub will understand that a merge has already
occurred, so when we get a random pull request to merge 0.9.3 into master
(seems to happen about twice a year), there will be nothing to do.

- Jim

Reply via email to