[gmx-developers] git release branch

[Roland Schulz]

Hi,

currently we are applying the a bugfix to both the HEAD and release branch
by committing it to one and then cherry-picking it in the other.

If I remember correctly the reason we decided to do this is:
There might be fixes in the release branch which are workarounds which
shouldn't be merged into the master branch (where the bug is fixed e.g. by a
new feature). Thus there are some fixes which should be merged into "master"
and there are others which should not be merged into "master".

The disadvantage of cherry-pick is that git does not know that a commit and
the cherry-picked copy in a different branch a identical. This has several
disadvantages:
- There is no command listing the commands which haven't been merged into
"master" yet.
- The log between the "master" and release branch lists also commits which
are applied to both
- It makes it more difficult to back-port features (producing more merge
conflicts)

Thus I suggest the following strategy instead:

- All bug-fixes are committed to the release branch first (if
one accidentally commits to the "master" branch see below)
- If it is a workaround which shouldn't be merged into master this should be
noted in the commit message
- Next one checks that the release branch doesn't contain any unmerged
commits (git log mater..release - where release is the name of the release
branch i.e. currently "release-4-0-patches")
- If it does contain unmerged commits, one checks that it is clear whether
the commits are supposed to be merged or not (and asks the author if it is
not clear)
- Next one merges the release branch into the "master" branch (git checkout
master; git merge release)
- If the release branch contained one or more workarounds which shouldn't be
included into the "master" branch one reverts those with "git revert -n; git
commit --amend"

This way it is always clear which commits are bug-fixes and which are
workarounds and the git logs reflect this difference. Also all the problems
from above (listing unmerged commits, log between versions, back-port) are
solved.

I don't think it is possible to switch the strategy at the moment. Instead I
propose to switch the strategy after the release of 4.5.

What do you think? Should we change the policy in this way? I have tried it
on a small test repository and the strategy seems to work.

Roland

Minor detail:
In case one has accidentally committed a bug-fix  into the "master" branch:
- One cherry-picks it into the release branch
- If the bug-fix commit in the master branch isn't committed yet: one can
rebase or reset it to remove the commit
- If it is already committed: one can either revert it or merge and fix
potential conflict in the merge


-- 
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20100301/d3f31d54/attachment.html>