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