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

[Mark Abraham]

----- Original Message -----
From: Roland Schulz <roland at utk.edu>
Date: Tuesday, March 9, 2010 2:26
Subject: Re: [gmx-developers] Accidental push of merge, was: git release	branch
To: Discussion list for GROMACS development <gmx-developers at gromacs.org>

> Sure. 
> I'm happy to put a cleaned up version (e.g. with code highlighting for the commands to paste) to the wiki.> 
> Could whoever manages the wiki check why I'm not allowed to edit pages? 

Some pages can't be edited. Overall site availability is not rock-steady, so please try again another time. Editing is fine for me at time of writing this email.

Mark
 
> I can login but afterwards the Edit Link is still grey and can't be clicked.> I tested it with Chrome 5.0.307.11 beta and Firefox 3.5.8.> 
> My user is: rolandschulz.

> 
> Thanks> 
> Roland> 
> 
> On Mon, Mar 8, 2010 at 2:10 AM, David van der Spoel <spoel at xray.bmc.uu.se> wrote:


> 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
> 
-- 
> 
gmx-developers mailing list

> gmx-developers at gromacs.org

> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> 
Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-developers-request at gromacs.org.

> 
> > 
> -- 
> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
> 865-241-1537, ORNL PO BOX 2008 MS6309


> -- 
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the 
> www interface or send it to gmx-developers-request at gromacs.org.