[Development] [IMPORTANT] your commits in stable branch perhaps lost after dev branch merged

[Frederik Gladhorn]

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
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
-- 
Best regards,
Frederik Gladhorn
Senior Software Engineer - Digia, Qt
Visit us on: http://qt.digia.com