[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
Roland
>
>
>
>> 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