Merge or Cherry-Pick?

[Johannes Sixt]

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