[gmx-developers] Accidental push of merge, was: git release branch

[David van der Spoel]

On 2010-03-08 07.04, Roland Schulz wrote:
> Hi,
>
> I'm sorry! I just accidentally pushed from a repository where I had
> merged in release-4-0-patches.
>
> I merged with "git merge -s ours release-4-0-patches"

Maybe you or another healthy volunteer can write a step by step howto 
for fixing bugs in the release branch and subsequent merge into the head 
branch. It should preferentially be cut-and-paste stuff...


>
> man git-merge: "This resolves any number of heads, but the result of the
> merge is always the current branch head. It is meant to be used to
> supersede old
>             development history of side branches."
> Or put another way (stackoverflow): "to pull in another [branch], but
> throw away all of the changes that [branch] introduces.
> This keeps the history of a branch without any of the effects of the
> branch."
>
> Thus I merged in the history of release-4-0-patches without changing any
> files in "master".
>
> Thus the good news is that no file was changed by my mistake.
> The bad news is that the history was changed. The history of master now
> also includes the history of release-4-0-patches. This makes most
> bug-fixes now appear twice. Sorry!
>
> I can't undo this because rewriting the history, would produce very
> weird merge conflicts if someone had already pulled after
> I accidentally pushed this merge.
>
> One potential good effect: If we want we can start using the strategy to
> always merge bug fixes from the release branch instead of
> cherry-picking. Because now git knows that the master branch includes
> all bug-fixes up to this point. And thus will merge only further
> bug-fixes. I'd suggest this strategy as explained in the earlier mail.
> See below for detailed explanation of this strategy.
>
> Sorry again for the mistake.
>
> Roland
>
> On Mon, Mar 1, 2010 at 10:02 PM, Roland Schulz <roland at utk.edu
> <mailto:roland at utk.edu>> wrote:
>
>     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
>     <http://cmb.ornl.gov>
>     865-241-1537, ORNL PO BOX 2008 MS6309
>
>
>
>
> --
> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov <http://cmb.ornl.gov>
> 865-241-1537, ORNL PO BOX 2008 MS6309
>


-- 
David van der Spoel, Ph.D., Professor of Biology
Dept. of Cell & Molec. Biol., Uppsala University.
Box 596, 75124 Uppsala, Sweden. Phone:	+46184714205.
spoel at xray.bmc.uu.se    http://folding.bmc.uu.se