On Wednesday 10 November 2010 15:51:26 Buddenhagen Oswald (Nokia-MS-Qt/Berlin) wrote: > 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.
SHA1 recored in JIRA, merges inside the branch, ... Are you trying to use git like you would use svn? _______________________________________________ Opengov mailing list Opengov@qt-labs.org http://lists.qt-labs.org/listinfo/opengov
