On Wed, Nov 10, 2010 at 3:37 PM, Oswald Buddenhagen <oswald.buddenha...@nokia.com> wrote: > addendum: > > On Wed, Nov 10, 2010 at 07:22:21PM +0100, Buddenhagen Oswald > (Nokia-MS-Qt/Berlin) wrote: >> so instead we cherry-pick the merges themselves, like every other >> commit. > >> and that actually works out of the box. >> > actually, it doesn't (it doesn't make the commit a merge). > > but that's easily substituted by doing a regular merge (using the second > parent from the merge commit to be picked). only if conflicts appear, > checkout --ours and apply the diff of the merge on top, add -u, commit. > more or less.
Hi there. One of the problems with the current qt git repository is that there are way too many merges, most of them unnecessary. It's difficult to follow the development due to all the pollution there. For example, from the top 1000 commits on qt.git right now, 37.6% are merge commits! My suggestion would be: git cherry-pick if it's one commit; If not, then merge on a temporary branch, rebase with the mainline and just then merge (fast-forward). git merge (non fast-forward) should be saved for cases when it makes sense to think of the development happening as a fork (for example, to implement a complex feature or when integrating an old branch). Just my 2 cents. :-) Cheers, - Ademar -- Ademar de Souza Reis Jr. <ademar.r...@openbossa.org> OpenBossa Labs - Instituto Nokia de Tecnologia _______________________________________________ Opengov mailing list Opengov@qt-labs.org http://lists.qt-labs.org/listinfo/opengov
