On Thu, Nov 11, 2010 at 02:23:04PM +0100, Macieira Thiago (Nokia-MS-Qt/Oslo) wrote: > Em Quinta-feira, 11 de Novembro de 2010, às 11:55:36, Oswald Buddenhagen > escreveu: > > > A merge that was successful at one point can fail when > > > rebased/remerged. > > > > of course, but that's no different from any other commit in the > > queue. [...] > > The point is that you can't always rebase. If you want to preserve the > commits and they can't be rebased (because they were done 6 months ago > and are part of a 500-change feature development), the only way is to > merge. > yes. so? you still just replay the merge. the first parent is different (because the target branch moved on), while the second parent is the same as in the original merge (and all commits in that branch are preserved).
on top of that, in the optimal (hopefully usual) case, the long-lived feature development would happen in a CI-controlled branch on the same system and thus the merges would be directly permitted. if a "foreign" branch gets merged, the system should probably demand confirmation that it really should pick only the merge, not rebase the entire branch. on a slightly related topic, i wonder what we will do about secret branches (there's no way to exclude that on the nokia side, and 3rd parties may want that option as well). they could all live in the same system and just have appropriate acls (which would have to be lifted before the merge into a less protected branch is allowed). but if we continue with the paranoia we have regarding the jiras, we would use separate instances of the CI system. from there, we could have a way to import entire pre-checked branches including all meta data (merge requests incl. reviews, test results, etc.) into the public system, or we could merge them as "foreign" branches as outlined above. _______________________________________________ Opengov mailing list Opengov@qt-labs.org http://lists.qt-labs.org/listinfo/opengov
