Hi Buga, Igor Djordjevic <igor.d.djordjevic@xxxxxxxxx> writes: [...] > That said, *if* we decide we like temporary commit U1' == U2' consistency > check (especially for non-interactive rebase, maybe), we can produce > these after the fact for the sake of the check only. I don't believe interactive vs. non-interactive split is actually helpful. I'd consider non-interactive just a special case of interactive when user didn't edit the todo list, nothing more. No special treatment should be required. For one, consistency checks in both modes has similar importance, even if only because there could be parts of history being interactively rebased which the user didn't intend to edit, nor actually edited during given session. Now let me get back to pros and cons of the two approaches to rebasing merges we have. Below I still advocate my approach by further discussing the differences, but simultaneously I'd like to emphasize that whatever particular way of rebasing merges will finally be used, it will be a huge step forward and I'm glad I've raised the issue in the first place. First, please consider the fact that my "rebase sides" method has yet another nice property: it reduces back to original "rebase the commit" operation when you apply it to a non-merge commit. In other words, it's true generalization on top of rebasing of simple commit. OTOH, Phillip's approach, when reduced to non-merge commit, still does a version of rebase, but very specific one, and in inverse manner. I.e., rather than merging changes of the commit to be rebased into the new base, it merges changes introduced by the new base into the commit being rebased. One consequence is that when conflict occurs, Phillip's approach will give surprising order of ours vs theirs changes, inverted with respect to those of the usual rebase of non-merge commit, while my approach will give exact non-merge commit semantics. It could likely be fixed by slightly modifying Phillip's approach, but it will make its implementation more complex. Another consequence is that, provided my version is used, all options that tune "simple commit rebase" behavior will automagically work for rebasing merge commits, in exactly the same manner. OTOH, Phillip's approach, without special attention in implementation, will do the same thing no matter what -m -s, or -X options say. Yet another consequence is that my approach will likely result in better code reuse. Even though mine seems to be harder to implement stand-alone than Phillip's one, it should be actually easier to implement inside the "git rebase", as it will use exactly the same machinery that "git rebase" already uses to rebase simple commits, adding only final "git merge-recursive" (or "git merge-resolve", or "git merge-octopus", -- any of them will do the job), which current implementation already performs as well, for re-creating merges from scratch. Second thought, unrelated to the above. To me it seems that my "rebasing sides" approach, being entirely symmetric, is cleaner than incremental merging suggested by Phillip, as with my approach one will still deal with branches independently, in the same way as for simple commits, until the single final merge operation. This comes with drawback of 1 additional step in my approach when compared to the Phillip's one though, but then mine has definitely no issues with the exact order of merges. Overall, to me it seems that unmodified Phillip's approach will bring unnecessarily wide set of new user experiences, and fixing it will require some tricks in implementation, for no apparent reason. -- Sergey
