On Thu, Nov 11, 2010 at 04:05:57PM +0100, Goffart Olivier (Nokia-MS-Qt/Oslo) wrote: > On Thursday 11 November 2010 15:55:50 Buddenhagen Oswald (Nokia-MS-Qt/Berlin) > wrote: > > On Thu, Nov 11, 2010 at 02:44:33PM +0100, Goffart Olivier > > (Nokia-MS-Qt/Oslo) wrote: > > > You can also write comment such as: > > > "This bug was introduced with commit 4a4e56abf" > > > > then the commit would be either already published (through CI) and > > thus have a stable sha1, or the fix should be squashed into it. > > Not if user starts testing the bleeding-edge banch. > what exactly a a "bleeding-edge branch"? why wouldn't it have gone through CI? the only not CI-checked commits should be the developers' local commits. then they submit to the system (automated with the to-be git-qt-push script) and rebase against the integration results (as we control the cherry-picking/rebasing process, we can have a git-qt-pull which knows exactly how to rebase).
> > > "Should be already fixed in the bleeding-edge branch with commit > > > 89d56f42" > > > > you just can't refer to commits until they went through CI. > > Yes you can. > no, because it makes no sense. > Really, I think you should not try to preserve a linear history at all cost. > i'm not. i'm trying to preserve linear history inside long-lived branches. rebasing merge commits doesn't change anything about the branches themselves, only about their merge points. the whole reason for the merge replaying feat is making merges not different from any other submission as far as the CI system goes. _______________________________________________ Opengov mailing list Opengov@qt-labs.org http://lists.qt-labs.org/listinfo/opengov
