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

[Roland Schulz]

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"

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> 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
> 865-241-1537, ORNL PO BOX 2008 MS6309
>



-- 
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/20100308/3d64ac53/attachment.html>