On Thu, Feb 10, 2011 at 9:35 PM, Johannes Sixt <j.s...@viscovery.net> wrote: > Am 2/9/2011 18:28, schrieb John Layt: >> On Tuesday 08 February 2011 17:49:12 Nicolás Alvarez wrote: >>>>> Or should I give up and cherry-pick ? (I'd really like not to). >>>> >>>> My recommendation: Keep the fix in 4.6 only for the moment. Just wait >>>> until the initial merge has happened - and lets hope (HOPE BIG TIME) that >>>> the person doing that merge knows what s/he is doing! >>> >>> I have now merged 4.6 into master in kde-workspace. >> >> Great, so now I can try merge my outstanding forward-ports instead of cherry- >> picking? Just so I don't mess it up, what's the correct procedure to do so? >> And after the merge, is there anything else I need to do (Ben's warning about >> pull after merge is ringing in my ears here). > > Nicolás's merge commit message says: > > "... Everything in 4.6 was verified to be already forward-ported > into master, so we're not losing anything. ..." > > Therefore, I assume that you haven't pushed your changes, yet. Do this: > > - Rebase your changes on top of current upstream 4.6 branch (7d537a3932). > You can use 'git pull --rebase' for this purpose, if you want. (Then run > the usual tests.) > > - Checkout current upstream master. For example: > > git fetch > git checkout origin/master > > (This detaches HEAD, and I'm proposing this procedure because I assume > that you have private changes in your local master branch; those private > changes should not be involved in the merge procedure we are talking about > here.) > > - git merge KDE/4.6. Use 'git commit --amend' to remove the ugly "into > HEAD" to pretend that you had branch master checked out ;) > > - Run tests. If everything is fine, push the merge result:
Note that test results should be compared with the results of prior runs under master and KDE/4.6, as some tests may already be failing. > > git push origin KDE/4.6 This is wrong, as it would try to push the content of HEAD (the merge of origin/KDE/4.6 into a checkout of origin/master) into KDE/4.6. > git push origin HEAD:master > > If any of these two pushes fail (because someone else was faster with a > push), repeat the entire procedure. > > - You can now do with your local changes on master what you do if someone > else had updated upstream master, for example, pull --rebase: > > git checkout master > git pull --rebase > > ----- > For illustration, what Ben said is disallowed is this sequence of commands: > > # after the very first rebase mentioned above > # instead of continuing with 'git fetch' > git checkout origin/master > git merge KDE/4.6 > git push HEAD:master # fails because, OOPS, I'm not up-to-date > git pull --rebase # DO NOT DO THIS > git push HEAD:master # would succeed, but the merge is lost This is correct. > > -- Hannes > Regards, Ben Cooksley KDE Sysadmin