Sure. <div><br></div><div>I'm happy to put a cleaned up version (e.g. with code highlighting for the commands to paste) to the wiki.</div><div><br></div><div>Could whoever manages the wiki check why I'm not allowed to edit pages? </div>
<div><br></div><div>I can login but afterwards the Edit Link is still grey and can't be clicked.</div><div>I tested it with Chrome 5.0.307.11 beta and Firefox 3.5.8.</div><div><br></div><div>My user is: rolandschulz.</div>
<div><br></div><div>Thanks</div><div><br></div><div>Roland</div><div><br></div><div><br><div class="gmail_quote">On Mon, Mar 8, 2010 at 2:10 AM, David van der Spoel <span dir="ltr"><<a href="mailto:spoel@xray.bmc.uu.se">spoel@xray.bmc.uu.se</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On 2010-03-08 07.04, Roland Schulz wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I'm sorry! I just accidentally pushed from a repository where I had<br>
merged in release-4-0-patches.<br>
<br>
I merged with "git merge -s ours release-4-0-patches"<br>
</blockquote>
<br></div>
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...<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div class="h5">
<br>
man git-merge: "This resolves any number of heads, but the result of the<br>
merge is always the current branch head. It is meant to be used to<br>
supersede old<br>
development history of side branches."<br>
Or put another way (stackoverflow): "to pull in another [branch], but<br>
throw away all of the changes that [branch] introduces.<br>
This keeps the history of a branch without any of the effects of the<br>
branch."<br>
<br>
Thus I merged in the history of release-4-0-patches without changing any<br>
files in "master".<br>
<br>
Thus the good news is that no file was changed by my mistake.<br>
The bad news is that the history was changed. The history of master now<br>
also includes the history of release-4-0-patches. This makes most<br>
bug-fixes now appear twice. Sorry!<br>
<br>
I can't undo this because rewriting the history, would produce very<br>
weird merge conflicts if someone had already pulled after<br>
I accidentally pushed this merge.<br>
<br>
One potential good effect: If we want we can start using the strategy to<br>
always merge bug fixes from the release branch instead of<br>
cherry-picking. Because now git knows that the master branch includes<br>
all bug-fixes up to this point. And thus will merge only further<br>
bug-fixes. I'd suggest this strategy as explained in the earlier mail.<br>
See below for detailed explanation of this strategy.<br>
<br>
Sorry again for the mistake.<br>
<br>
Roland<br>
<br>
On Mon, Mar 1, 2010 at 10:02 PM, Roland Schulz <<a href="mailto:roland@utk.edu" target="_blank">roland@utk.edu</a><br></div></div><div><div></div><div class="h5">
<mailto:<a href="mailto:roland@utk.edu" target="_blank">roland@utk.edu</a>>> wrote:<br>
<br>
Hi,<br>
<br>
currently we are applying the a bugfix to both the HEAD and release<br>
branch by committing it to one and then cherry-picking it in the other.<br>
<br>
If I remember correctly the reason we decided to do this is:<br>
There might be fixes in the release branch which are workarounds<br>
which shouldn't be merged into the master branch (where the bug is<br>
fixed e.g. by a new feature). Thus there are some fixes which should<br>
be merged into "master" and there are others which should not be<br>
merged into "master".<br>
<br>
The disadvantage of cherry-pick is that git does not know that a<br>
commit and the cherry-picked copy in a different branch a identical.<br>
This has several disadvantages:<br>
- There is no command listing the commands which haven't been merged<br>
into "master" yet.<br>
- The log between the "master" and release branch lists also commits<br>
which are applied to both<br>
- It makes it more difficult to back-port features (producing more<br>
merge conflicts)<br>
<br>
Thus I suggest the following strategy instead:<br>
<br>
- All bug-fixes are committed to the release branch first (if<br>
one accidentally commits to the "master" branch see below)<br>
- If it is a workaround which shouldn't be merged into master this<br>
should be noted in the commit message<br>
- Next one checks that the release branch doesn't contain any<br>
unmerged commits (git log mater..release - where release is the name<br>
of the release branch i.e. currently "release-4-0-patches")<br>
- If it does contain unmerged commits, one checks that it is clear<br>
whether the commits are supposed to be merged or not (and asks the<br>
author if it is not clear)<br>
- Next one merges the release branch into the "master" branch (git<br>
checkout master; git merge release)<br>
- If the release branch contained one or more workarounds which<br>
shouldn't be included into the "master" branch one reverts those<br>
with "git revert -n; git commit --amend"<br>
<br>
This way it is always clear which commits are bug-fixes and which<br>
are workarounds and the git logs reflect this difference. Also all<br>
the problems from above (listing unmerged commits, log between<br>
versions, back-port) are solved.<br>
<br>
I don't think it is possible to switch the strategy at the moment.<br>
Instead I propose to switch the strategy after the release of 4.5.<br>
<br>
What do you think? Should we change the policy in this way? I have<br>
tried it on a small test repository and the strategy seems to work.<br>
<br>
Roland<br>
<br>
Minor detail:<br>
In case one has accidentally committed a bug-fix into the "master"<br>
branch:<br>
- One cherry-picks it into the release branch<br>
- If the bug-fix commit in the master branch isn't committed yet:<br>
one can rebase or reset it to remove the commit<br>
- If it is already committed: one can either revert it or merge and<br>
fix potential conflict in the merge<br>
<br>
<br>
--<br>
ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov" target="_blank">cmb.ornl.gov</a><br></div></div>
<<a href="http://cmb.ornl.gov" target="_blank">http://cmb.ornl.gov</a>><div class="im"><br>
865-241-1537, ORNL PO BOX 2008 MS6309<br>
<br>
<br>
<br>
<br>
--<br></div>
ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov" target="_blank">cmb.ornl.gov</a> <<a href="http://cmb.ornl.gov" target="_blank">http://cmb.ornl.gov</a>><div class="im"><br>
865-241-1537, ORNL PO BOX 2008 MS6309<br>
<br>
</div></blockquote>
<br>
<br>
-- <br>
David van der Spoel, Ph.D., Professor of Biology<br>
Dept. of Cell & Molec. Biol., Uppsala University.<br>
Box 596, 75124 Uppsala, Sweden. Phone: +46184714205.<br>
<a href="mailto:spoel@xray.bmc.uu.se" target="_blank">spoel@xray.bmc.uu.se</a> <a href="http://folding.bmc.uu.se" target="_blank">http://folding.bmc.uu.se</a><br><font color="#888888">
-- <br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov">cmb.ornl.gov</a><br>865-241-1537, ORNL PO BOX 2008 MS6309<br>
</div>