On Fri, Nov 12, 2010 at 04:20:20PM +0100, Macieira Thiago (Nokia-MS-Qt/Oslo) wrote: > Em Sexta-feira, 12 de Novembro de 2010, às 11:56:30, Oswald Buddenhagen > escreveu: > > i don't see why we should exclude merge commits from the "avoid > > unnecessary merges" rule if we can do better with rather little > > effort. > > Look back at my example: > ... C1---C2---C3---C4---C5---C6---C7 [mainline] > \ \ > \-F1---F2-+-M1---F3 [feature] > > This is what was submitted and the CI rejected because C7 and F3 didn't merge > cleanly without human intervention. How do you solve this? > as usual: i merge C7 into F3, resolve conflicts, commit. then i push it to the ci system. ci repeats the merge by using the second parent from my commit. the merge fails. it resets all changes, then replays the diff (against the first parent) from my merge. if that goes ok, cool. if it goes wrong (which can happen only because new conflicts were added after C7), reject the commit and let me repeat the merge (which is easy, because i have rerere). this is CI-wise exactly the same workflow as for any other commit after it failed to merge because the world moved on, and that's the whole point of the exercise.
so let's now please follow tobias' request to get back to doing some real work instead of disputing the feasibility of automating a minor graph optimization. _______________________________________________ Opengov mailing list Opengov@qt-labs.org http://lists.qt-labs.org/listinfo/opengov
