[gmx-developers] Accidental push of merge, was: git release branch
David van der Spoel
spoel at xray.bmc.uu.se
Tue Mar 9 19:41:51 CET 2010
On 2010-03-09 19.28, Roland Schulz wrote:
>
>
> On Mon, Mar 8, 2010 at 2:10 AM, David van der Spoel
> <spoel at xray.bmc.uu.se <mailto: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
>
Great! Now even I can do it...
Thanks.
> 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>
> <mailto: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>
> <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> <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 <mailto:spoel at xray.bmc.uu.se>
> http://folding.bmc.uu.se
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org <mailto: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
> <mailto:gmx-developers-request at gromacs.org>.
>
>
>
>
> --
> 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
More information about the gromacs.org_gmx-developers
mailing list