> 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 [email protected] http://lists.qt-project.org/mailman/listinfo/development
