[Development] [IMPORTANT] your commits in stable branch perhaps lost after dev branch merged
frederik.gladhorn at digia.com
Fri Mar 22 18:07:38 CET 2013
Torsdag 21. mars 2013 20.27.33 skrev Oswald Buddenhagen:
> 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
> i also identified a second commit which appears to have been mis-merged
> (comment added to original change).
> 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
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
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
Senior Software Engineer - Digia, Qt
Visit us on: http://qt.digia.com
More information about the Development