Hi,<div><br></div><div>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. </div><div><br></div><div>If I remember correctly the reason we decided to do this is:</div>
<div>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".</div>
<div><div><br></div><div>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:</div><div>- There is no command listing the commands which haven't been merged into "master" yet.</div>
<div>- The log between the "master" and release branch lists also commits which are applied to both</div><div>- It makes it more difficult to back-port features (producing more merge conflicts)</div><div><br></div>
<div>Thus I suggest the following strategy instead:</div><div><br></div><div>- All bug-fixes are committed to the release branch first (if one accidentally commits to the "master" branch see below)</div><div>- If it is a workaround which shouldn't be merged into master this should be noted in the commit message</div>
<div>- 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")</div><div>
- 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)</div>
<div>- Next one merges the release branch into the "master" branch (git checkout master; git merge release) </div><div>- 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"</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>Roland</div><div><br></div><div>Minor detail:</div><div><div>In case one has accidentally committed a bug-fix into the "master" branch:</div><div>- One cherry-picks it into the release branch</div>
<div>- If the bug-fix commit in the master branch isn't committed yet: one can rebase or reset it to remove the commit</div><div>- If it is already committed: one can either revert it or merge and fix potential conflict in the merge</div>
<div><br></div></div><div><br>-- <br>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov">cmb.ornl.gov</a><br>865-241-1537, ORNL PO BOX 2008 MS6309<br>
</div></div>