[gmx-developers] Accidental push of merge, was: git release branch
David van der Spoel
spoel at xray.bmc.uu.se
Mon Mar 8 08:10:29 CET 2010
On 2010-03-08 07.04, Roland Schulz wrote:
> 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
> 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.
> On Mon, Mar 1, 2010 at 10:02 PM, Roland Schulz <roland at utk.edu
> <mailto:roland at utk.edu>> wrote:
> 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.
> Minor detail:
> In case one has accidentally committed a bug-fix into the "master"
> - 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
> 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
More information about the gromacs.org_gmx-developers