Re: [Development] [IMPORTANT] your commits in stable branch perhaps lost after dev branch merged
On 03/21/2013 05:12 PM, Qi Liang wrote: Let's be more clear: no commits were lost. They are all still present. However, due to conflicts, some changes may have been improperly resolved. This is no different than any other merge, in any direction. Yes, it's lost because of conflict resolve. And we recorded the conflicts information in merge commit, that's better than before, the merge commits in Qt 4. This is also a good reason to make an effort to add unit tests that verify your fix, however banal they might be, because there's a much smaller chance that the unit test will disappear in the merge than the bug fix. -- Eskil ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [IMPORTANT] your commits in stable branch perhaps lost after dev branch merged
Torsdag 21. mars 2013 20.27.33 skrev Oswald Buddenhagen: hi, On Thu, Mar 21, 2013 at 02:33:30PM +, 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@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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [IMPORTANT] your commits in stable branch perhaps lost after dev branch merged
Hi, all, I think it's important, your commits in stable branch perhaps lost after dev branch merged. At least we found one case: https://codereview.qt-project.org/51722 Before the big merge happened recently, we normally will fix some bugs in stable branch(5.0), and they will be merged into dev branch regularly, normally manually done by Frederik Gladhorn(thanks for his work). But this time, we didn't do the regular stable-dev merge just before the current unfinished BIG dev-stable merge. When dev-stable merge happened, the merger maybe had chosen the dev code to override the stable one when conflicts happened. Then some commits in stable maybe lost. If you have some recent commits in stable, pls check whether it is still in stable after the dev-stable merge. For example, for qtbase, last stable-dev happened March 6, 49a2ec05b43b49d06dba8c6909c9df8d308e127d. And dev-stable is March 20, e5a11fbb3251a98fafd6bebf0b6fc366acb19088. BTW, we also have some merges from or to release, better to also check them. This is the first time which we merge dev-stable in qt history, I think. Regards, Liang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [IMPORTANT] your commits in stable branch perhaps lost after dev branch merged
On quinta-feira, 21 de março de 2013 14.33.30, Qi Liang wrote: Hi, all, I think it's important, your commits in stable branch perhaps lost after dev branch merged. At least we found one case: https://codereview.qt-project.org/51722 Let's be more clear: no commits were lost. They are all still present. However, due to conflicts, some changes may have been improperly resolved. This is no different than any other merge, in any direction. Before the big merge happened recently, we normally will fix some bugs in stable branch(5.0), and they will be merged into dev branch regularly, normally manually done by Frederik Gladhorn(thanks for his work). But this time, we didn't do the regular stable-dev merge just before the current unfinished BIG dev-stable merge. When dev-stable merge happened, the merger maybe had chosen the dev code to override the stable one when conflicts happened. Then some commits in stable maybe lost. If you have some recent commits in stable, pls check whether it is still in stable after the dev-stable merge. When there's a conflict the merger does not know how to resolve, the merger asks for help. Choosing unconditionally one side is a bad idea. For example, for qtbase, last stable-dev happened March 6, 49a2ec05b43b49d06dba8c6909c9df8d308e127d. And dev-stable is March 20, e5a11fbb3251a98fafd6bebf0b6fc366acb19088. BTW, we also have some merges from or to release, better to also check them. This is the first time which we merge dev-stable in qt history, I think. It's not the first dev-stable merge. The direction does not matter. This merge is no different than the previous ones. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [IMPORTANT] your commits in stable branch perhaps lost after dev branch merged
Let's be more clear: no commits were lost. They are all still present. However, due to conflicts, some changes may have been improperly resolved. This is no different than any other merge, in any direction. Yes, it's lost because of conflict resolve. And we recorded the conflicts information in merge commit, that's better than before, the merge commits in Qt 4. When there's a conflict the merger does not know how to resolve, the merger asks for help. Choosing unconditionally one side is a bad idea. I don't think the merger has enough time to do that. And under open governance gerrit, there is a risk for merge, maybe some incoming commits will break the merge. It's not the first dev-stable merge. The direction does not matter. This merge is no different than the previous ones. Had we done any merge from Qt 4.x to 4.x-1 or similar before? Before, we think stable as 5.0 and dev as 5.1, then we prefer bug fixes in stable, features in dev. But now, I don't think stable and dev are much different in current release cycle, just a time difference, all changes in dev will be in stable after this BIG merge procedure, just means the users of stable branch will get the fixes in a short time or a few months later. Regards, Liang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [IMPORTANT] your commits in stable branch perhaps lost after dev branch merged
On Thursday 21 March 2013 16:12:51 Qi Liang wrote: Let's be more clear: no commits were lost. They are all still present. However, due to conflicts, some changes may have been improperly resolved. This is no different than any other merge, in any direction. Yes, it's lost because of conflict resolve. And we recorded the conflicts information in merge commit, that's better than before, the merge commits in Qt 4. When there's a conflict the merger does not know how to resolve, the merger asks for help. Choosing unconditionally one side is a bad idea. I don't think the merger has enough time to do that. He has too take that time. It is the responsability of the merger to do proper work. Merging is not an easy task. (I know it, I was doing the merge during Qt 4.x times) It is easy for someone unexperimented to mess up. Which is why I think only experimented developer should do the merge. And under open governance gerrit, there is a risk for merge, maybe some incoming commits will break the merge. It's not the first dev-stable merge. The direction does not matter. This merge is no different than the previous ones. Had we done any merge from Qt 4.x to 4.x-1 or similar before? Before, we think stable as 5.0 and dev as 5.1, then we prefer bug fixes in stable, features in dev. A merge is between two branches. And the merge operation is commutative. Think about it like: merge(stable , dev) == merge (dev, stable) // usually tmp = merge(stable, dev); dev = tmp; // this time tmp = merge(stable, dev); stable = tmp; The merge operation is the same. The main difference is that this time the merger apparently screw up. But now, I don't think stable and dev are much different in current release cycle, just a time difference, all changes in dev will be in stable after this BIG merge procedure, just means the users of stable branch will get the fixes in a short time or a few months later. The merge was no bigger than usual. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [IMPORTANT] your commits in stable branch perhaps lost after dev branch merged
On quinta-feira, 21 de março de 2013 16.12.51, Qi Liang wrote: When there's a conflict the merger does not know how to resolve, the merger asks for help. Choosing unconditionally one side is a bad idea. I don't think the merger has enough time to do that. And under open governance gerrit, there is a risk for merge, maybe some incoming commits will break the merge. The merger must do that. Always ask for help. If no help comes in reasonable time, then and only then should the merger make a decision based on available information. And then post to the mailing list. It's not the first dev-stable merge. The direction does not matter. This merge is no different than the previous ones. Had we done any merge from Qt 4.x to 4.x-1 or similar before? Before, we think stable as 5.0 and dev as 5.1, then we prefer bug fixes in stable, features in dev. We've always done merges between versions N and N+1. If you declare M = N + 1, then we did merges between M - 1 and M. Any way you do this, we've done this before. The direction does not matter. But now, I don't think stable and dev are much different in current release cycle, just a time difference, all changes in dev will be in stable after this BIG merge procedure, just means the users of stable branch will get the fixes in a short time or a few months later. The only difference this time is that we updated the stable (previous version) branch. That's *really* the only difference. Everything else is the same as it has always been ever since we introduced Git usage for Qt, back in 2008. (I'm sure there was a blog, with a picture of Lars and Simon talking to the sysadmins, turning the Git repository live for the first time, but I can't find it) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [IMPORTANT] your commits in stable branch perhaps lost after dev branch merged
Merging is not an easy task. (I know it, I was doing the merge during Qt 4.x times) It is easy for someone unexperimented to mess up. Which is why I think only experimented developer should do the merge. Not that easy like Qt 4.x ages(we only have 1 repo, and we could do that merge per week or per month, or just before a release), now we have about 10 repos, and after open governance, changes are more. And sometimes, a merge depends on another merge(just like qtdeclarative depends on qtbase). stable-dev merges happened like daily. A merge is between two branches. And the merge operation is commutative. Think about it like: merge(stable , dev) == merge (dev, stable) // usually tmp = merge(stable, dev); dev = tmp; // this time tmp = merge(stable, dev); stable = tmp; // usually or before stable = stable; // 4.x-1 dev = merge(stable, dev); // 4.x, stable-dev // this time stable = merge(dev, stable); // dev-stable dev = stable; // then here you can see stable doesn't have much meaning when release cycle is short enough. Regards, Liang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [IMPORTANT] your commits in stable branch perhaps lost after dev branch merged
On quinta-feira, 21 de março de 2013 10.06.00, Thiago Macieira wrote: (I'm sure there was a blog, with a picture of Lars and Simon talking to the sysadmins, turning the Git repository live for the first time, but I can't find it) Thanks to Daniel: http://blog.qt.digia.com/blog/2008/09/28/qt-cuter-than-before-443/ -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [IMPORTANT] your commits in stable branch perhaps lost after dev branch merged
On Thursday 21 March 2013 17:16:36 Qi Liang wrote: Merging is not an easy task. (I know it, I was doing the merge during Qt 4.x times) It is easy for someone unexperimented to mess up. Which is why I think only experimented developer should do the merge. Not that easy like Qt 4.x ages(we only have 1 repo, Having 1 big repo was not a good thing. The modularisation simplifies the marges because each merge is smaller, and also made by different people who knows the code base of their repository better. and we could do that merge per week or per month, or just before a release), I was doing the merge at least once a week. now we have about 10 repos, and after open governance, changes are more. And sometimes, a merge depends on another merge(just like qtdeclarative depends on qtbase). Dependencies should only go one way. (qtdeclarative depends on qtbase, but not the other way around) stable-dev merges happened like daily. They don't. Check the history, it is more like once a week or less. A merge is between two branches. And the merge operation is commutative. Think about it like: merge(stable , dev) == merge (dev, stable) // usually tmp = merge(stable, dev); dev = tmp; // this time tmp = merge(stable, dev); stable = tmp; // usually or before stable = stable; // 4.x-1 dev = merge(stable, dev); // 4.x, stable-dev // this time stable = merge(dev, stable); // dev-stable dev = stable; // then here you can see stable doesn't have much meaning when release cycle is short enough. Merge are commutative. merge(stable, dev) == merge(dev, stable) Think of it like a '+' 3 + 8 == 8 + 3 so stable = merge(dev, stable); or stable = merge(stable, dev); are exactly the same thing. [1] The only difference between this merge and the other merge is the branch to which it was commited, and the one who made the merge. The merge is no bigger than usual, and no more complicated. On the contrary, it was even smaller because the last stable-dev was [1] It actually has some difference, like the order of the chunks when one need to resolve the conflicts, but the resulting operation should be the same. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [IMPORTANT] your commits in stable branch perhaps lost after dev branch merged
hi, On Thu, Mar 21, 2013 at 02:33:30PM +, 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
