Hmm, why do it that way? If you specify the JIRA ID in the commit, the Fisheye (or potentially Crucible) integration with JIRA can show the related source changes no matter how many different or changed SHA1's are involved.
________________________________________ From: opengov-boun...@qt-labs.org [opengov-boun...@qt-labs.org] On Behalf Of Goffart Olivier (Nokia-MS-Qt/Oslo) Sent: Thursday, 11 November 2010 01:21 To: opengov@qt-labs.org Subject: Re: [Opengov] A few thoughts on Open Governance 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 _______________________________________________ Opengov mailing list Opengov@qt-labs.org http://lists.qt-labs.org/listinfo/opengov
