Merge or Cherry-Pick?

[Ben Cooksley]

On Thu, Feb 10, 2011 at 9:35 PM, Johannes Sixt <j.sixt at 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