ydirson@xxxxxxx writes: > I've been going through a couple of "rebase -i -r" lately, and would > like to share a couple of thoughts, starting with something looking > like a bug. I feel your pain and sympathize deeply. > > 1. when a merge has been done with "-s ours", rebase replays it without > any special options, I proceed with the manual resolution, and if I just > --continue, the rebase mechanism believes I want to drop the commit, which > could not be more wrong. I can still be careful myself, and use "git commit > --allow-empty" before --continue, but this feels awkward. > > Is there any compelling reason not record the merge here ? This looks like rather easy case to fix indeed. I mean empty commit issue, not the original cause of the problem. > > 2. more generally, when a merge has been done with special options, it > would be a useful help in solving conflicts if rebase could use the same > options. Maybe we could allow the rebase "merge" instruction to use more > merge options. The user would still have to edit the instruction sheet > manually for those, however, and we could then want "rebase -i" to fill > them automatically, but that would seem to require recording the merge > options somewhere to start with - maybe in a note. That could help now an then, but doesn't solve the problem in general, as, first, the behavior of merge algorithms could change over time, and, second, the merge could have been performed with external merge algorithm in the first place, including entirely manual merge, and after all, the person rebasing may have no idea at all how the original merge has been achieved. Recording information about merges at merge time has similar problems to recording information about renames, both being "obvious" solutions that in fact end-up being sub-optimal. Fortunately, we still have the original merge handy, that Git simply doesn't care to take into account, see below. > > 3. while it's made clear that any conflict resolution and amendments > have to be redone, maybe we could provide some support for a common > use case, namely "sink that commit/fixup down". The conflict > resolution would then be like "checkout $OLD && cherry-pick -n $FIXUP". > > Maybe this could be activated by a merge option in rebase-interactive > instructions, like "merge -C$OLD --fixup $F1 --fixup $F2". > > Would that seem reasonable ? I still (as this has been already heavily discussed some time ago) believe that the most reasonable solution to all this is to rebase merges rather than to throw them away. Redoing them, as Git does, is wrong choice in most cases as what it means is that Git, despite the option name --rebase-merges (and even better old name --preserve-merges), simply still throws away your precious merge commits, only then it substitutes something potentially entirely different for them, often silently. In addition to the problems you've encountered, silent drop of user content is possible, and what's worse than that for a content preserving tool? As a result, to be on the safe side, with current approach to handling merges during rebase, any non-trivial merge that is expected to be rebased (and how would one be sure it never will?) is to be very carefully performed in 2 commits: merge itself and fixups, otherwise chances are high fixups are silently lost during rebase. Further, even this two-step approach doesn't solve all the problems. For instance, issues with merges being originally performed with non-default algorithm still remain (as in your case 1.) Moreover, if we notice that default (or any thereof) algorithm itself could change over time, inherent problems with the policy of recreating merge commits from scratch during rebase get even more obvious. Overall, to get this right, Git should finally refrain (at least by default) from generally hopeless attempts to re-create merges from scratch on rebase. Instead it should try to actually rebase existing merges when user asks to preserve history shape. When and if automatic rebase fails, one of the options to resolve the issue, besides fixing rebase conflicts, is indeed to redo the merge, but then the user will be perfectly aware of particular re-merge, and will be responsible for the end result himself. -- Sergey
