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: git push origin 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 -- Hannes