Merge or Cherry-Pick?

[Johannes Sixt]

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).

-- Hannes