Em Quarta-feira, 10 de Novembro de 2010, às 15:51:26, Oswald Buddenhagen escreveu: > On Wed, Nov 10, 2010 at 03:32:59PM +0100, Macieira Thiago (Nokia-MS-Qt/Oslo) wrote: > > Em Quarta-feira, 10 de Novembro de 2010, às 15:03:55, Oswald Buddenhagen escreveu: > > > On Wed, Nov 10, 2010 at 02:43:37PM +0100, Goffart Olivier (Nokia-MS- Qt/Oslo) wrote: > > > > Things to think about: > > > > - What if we are talking in branch instead of patches? > > > > > > > > So the tool must have a ways to handle both single patches, or > > > > full branch (where sha-1 cannot be modified) > > > > > > we define that this cannot happen. everything is cherry-picked into a > > > long-lived branch. > > > > I don't think that is feasible. There are long-lived projects that branch > > out and work for a long time without being merged in. In that period, > > they merge back from the mainline or whatever branch they were tracking. > > where is the contradiction here? the merges *into* the long-lived branch > would be cherry-picked (whether literally or via some surrogate > mechanism which can actually do it) just like the (later) ones *from* > that branch.
Then I didn't get it.
My point is that long-lived branches must bypass the cherry-picking mechanism
when merging. Those must be submitted via a side mechanism to what Tor Arne
described.
--
Thiago Macieira - thiago.macieira (AT) nokia.com
Senior Product Manager - Nokia, Qt Development Frameworks
Sandakerveien 116, NO-0402 Oslo, Norway
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Opengov mailing list Opengov@qt-labs.org http://lists.qt-labs.org/listinfo/opengov
