[git fun] reticulated branch merges for 2.10.0b1 release

Hi all.

I hit a snag when finishing of the patch release which is worth
documenting on the list, in case we hit something like it again.

Some history:
Back in 2015 when 2.9.0b2 was released, I had to do some gymnastics in
order to merge from the Release_2_9_0b2 tag to master, This was due to a
public rebase of develop that happened around April 2015.

I also decided to change the way we create the licensed, timestamped
tarball, so instead of including an out of date year/version in the
source files and updating them on the branch when we cut a new release,
I introduced $$Version-Rel$$ and $$Year-Rel$$. These tokens are replaced
when the tarball is created with the appropriate build data.

The tangle:
I'm not 100% sure, but I think the critical issue was that in the first
attempt to cut a new release, I mistakenly committed the source with
tokens replaced with build data on to the release 2.9.0b2 branch, which
was then merged with master.

Fast forward to today, when I tried to merge onto master from the 2.10.0
branch, I discover that everything seems to go fine, but most source
files still have 2.9.0b2 in their license header.

After much head scratching, my solution was (roughly):

# update master from release branch
# try to update master as far as we can
git checkout master # update the master from repository
# make sure we've merged - -X theirs is possibly superstition here
git merge -X theirs releases/Release_2_10_0_Branch

# create a patch to fix the differences
git checkout releases/Release_2_10_0_Branch
git diff master > jv210_master.patch
# create a new branch for the patch.
git checkout -b releases/Release_2_10_0_Branch_fixmaster
# first need to merge from master to get the old headers
git merge -X ours master
# then commit the patch to fix the headers
git apply jv210_master.patch
git add -u
git commit --message "JAL-2089 update master for release 2.10.0b1"

#now merge the patch to the release and develop branches
git checkout releases/Release_2_10_0_Branch
git merge --no-ff releases_Release_2_10_0_Branch_fixmaster

# ... same for others
# in all cases, the merge should result in no updated files
# because the patch has already been applied.

# finally - merge the patch to master
git checkout master git
git merge releases/Release_2_10_0_Branch

Looking forward to not having to do this again for our next release !


Dr JB Procter, Jalview Coordinator, The Barton Group
Division of Computational Biology, School of Life Sciences
University of Dundee, Dundee DD1 5EH, UK.
+44 1382 388734 | www.jalview.org | www.compbio.dundee.ac.uk