On Thu, Nov 11, 2010 at 11:03:09AM +0100, Macieira Thiago (Nokia-MS-Qt/Oslo) wrote: > Replaying merges isn't very easy, as evidenced by the little use that > rebase -m has. > well, it's somewhat laborious and easy to botch up, thus usually not worth it. but given the constraints of the CI system it's fairly easy to automate it in a reliable way. maybe i should prototype a git-replay-merge.
> It also depends on the merges only happening in one direction and > requires that no conflict resolution happened in those merges. > that's simply not true as demonstrated in the cherry-pick substitution sequence a few posts back. the idea is to start a merge, and in case of conflict throw away all changes and then re-apply the diff against the target branch from the original merge commit (including merge conflict resolutions). > 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. it gets automatically set to revise and resubmit, and you repeat it. of course, you would have rerere.enabled=true (rerere.autoupdate=true is also very helpful), so you'd only need to resolve the new conflicts. that's in fact what i do to avoid a second merge when the target branch "runs away" while i'm resolving conflicts. _______________________________________________ Opengov mailing list Opengov@qt-labs.org http://lists.qt-labs.org/listinfo/opengov
