Merge or Cherry-Pick?

[Parker Coates]

On Tue, Feb 1, 2011 at 06:29, Johannes Sixt wrote:
> Am 2/1/2011 10:31, schrieb David Jarvie:
>> On Mon, January 31, 2011 11:27 pm, Thiago Macieira wrote:
>>> On Monday, 31 de January de 2011 23:34:39 Arno Rehn wrote:
>>>> I guess that won't quite work when there are commits specific to 4.6 in
>>>> the
>>>> 4.6 branch that shouldn't end up in master. And it clutters history with
>>>> tons of merges.
>>>
>>> Then let's solve the problem by not having anything specific to 4.6. If it
>>> belongs in the stable release, it belongs in the next stable release too.
>>
>> That's not always true. Some changes *will* be specific to 4.6, because
>> sections of code in master can get rewritten, features added or removed,
>> so the changes won't be applicable there.
>
> In such a situation, you make the merge anyway, but you resolve the
> ensuing conflicts by taking master's state (i.e., it amounts to a merge
> --ours). You should write in the message of the merge commit that the
> change made to 4.6 is not relevant on master anymore (and why it is not
> relevant anymore).

Another special and unavoidable case of this will be applications
bumping their stable version numbers. It seems weird to have a
"Updated version to 4.6.2" commit in a 4.7 master, for example, but I
guess that the (small) price one pays for mergeable stable branches.

Parker