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

Roland Schulz roland at utk.edu
Tue Mar 9 19:28:49 CET 2010

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...

I added it to  http://www.gromacs.org/Developer_Zone/Git/Git_Tutorial


>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20100309/f38cb53a/attachment.html>

More information about the gromacs.org_gmx-developers mailing list