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. > > "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. Really, I think you should not try to preserve a linear history at all cost. Rebasing does not work if there was any conflicts that were fixed in intermediate merges. This also is not good if sha-1 had been recorded in other commits (like "Revert commit 1e125a45") This is painfull if developers are still tracking the development branch. Example. Lighthouse developers are working on lighthouse-bleeding-edge branch. They do refactoring in this branch, meaining there are states in which some part are not working. But this is development anyway, so fine, they do 100+ commits there, sometimes merging from mainline. Then lighthouse-release branch is branched out of lighthouse-bleeding-edge, where bugfixes are applied, while some dev continue working on lighthouse- bleeding-edge Then once lighthouse-release is ready, it is proposed for integration into master master. We do not want to rebase this. Else the developer on lighthouse-bleeding-edge will have serious trouble again. Why are you trying to use git like svn? _______________________________________________ Opengov mailing list Opengov@qt-labs.org http://lists.qt-labs.org/listinfo/opengov
