Torsdag 21. mars 2013 20.27.33 skrev Oswald Buddenhagen: > hi, > > On Thu, Mar 21, 2013 at 02:33:30PM +0000, Qi Liang wrote: > > I think it's important, your commits in stable branch perhaps lost > > after dev branch merged. [...] > > to preclude further pointless panicking, i simply re-did the merge > and diffed the result. > > the hunk that was already identified as lost was indeed a simple > mis-merge. > > i also identified a second commit which appears to have been mis-merged > (comment added to original change). > > background: > > the merge was originally done by sergio (who also introduced the > mistakes, which is somewhat understandable, given how many merges there > were to do, and under which (perceived) time pressure). > > i amended and "rebased" the merge, and in the process accidentally > "stole" the attribution. later i reviewed the merge and missed the > mis-merges (mostly due to git's retarded (non-)display of conflict > resolution diffs). > > end of story. now move on.
I agree, there is no real damage done, we fixed up where the merges went wrong. My personal pain point was that the whole merge was a bit uncoordinated. As someone who has enjoyed merging branches lately, I can completely understand that it goes wrong, I messed up a few times too, especially in the beginning. I just have a few notes for those doing the merge: * be careful when doing merges; take time to actually review merges * don't disable unit tests because they block a merge, chances are your merge is wrong (this should be a no-brainer...) * if you haven't done much merging, grab someone else to resolve the conflicts, peer-merging is much more fun and less frustrating * check why you have a conflict, digging through git history is fun anyway * don't be ashamed to ask others who are responsible for the conflict, they will help you resolve it properly * don't keep on including more and more commits in your merge, it's just going to give you more breakage, it's fine to do two merge commits instead - there is no requirement to take HEAD of one branch, it's bad enough that the target branch is a moving target In this particular case, I would have appreciated more coordination. The merge was started when the stable->dev merges were all done but qtbase which was known not to integrate. The same problems broke the other direction, unsurprisingly. We could have taken much less time by choosing a good set of dev branch sha1s. Updating the merge with a few commits afterwards is no big deal, the diff will be small and things will go smother. Let's keep it rolling :) > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development -- Best regards, Frederik Gladhorn Senior Software Engineer - Digia, Qt Visit us on: http://qt.digia.com _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
