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
