| Issue 983: | merges should be cherry-picked | |
| 8 people starred this issue and may be notified of changes. | Back to list |
currently, even if in cherry-picking mode, gerrit will create a second merge when trying to apply a merge and this does not result in a fast-forward. this is suboptimal. the solution is replaying the merge properly: git merge --no-commit -s ours candidate^2 git cherry-pick -m 1 candidate the second step may fail with merge conflicts as any other commit, in which case the submitter needs to throw away the merge and repeat it. thanks to git rerere, he needs to resolve only the new conflicts. then he just pushes again (preferably after ensuring that the Change-Id is preserved).
May 27, 2011
well, the point of submitting merges in the first place is merging between long-lived branches. we want that to go through gerrit for process uniformity reasons. i won't insist on any particular terminology. one could also say that the merge is rebased, but then people start thinking of rewriting heaps of published history. see also the epic subthread starting at http://lists.qt-labs.org/public/opengov/2010-November/000170.html one difference to what i claimed in that thread is that the above two-step procedure is not only a fallback, but the only way to go. that's because one can "hide" additional changes inside the merge even if it is a clean merge to start with. |
|
| ► Sign in to add a comment |
Status: Accepted