Hi Buga, On Thu, 8 Mar 2018, Igor Djordjevic wrote: > On 08/03/2018 16:16, Igor Djordjevic wrote: > > > > > Unless we reimplement the octopus merge (which works quite a bit > > > differently from the "rebase merge commit" strategy, even if it is > > > incremental, too), which has its own challenges: if there are merge > > > conflicts before merging the last MERGE_HEAD, the octopus merge will exit > > > with status 2, telling you "Should not be doing an octopus.". While we > > > will want to keep merge conflict markers and continue with the "rebase the > > > original merge commit" strategy. > > > > > > [...] > > > > The thing is, in my opinion, as long as we are _rebasing_, you can`t > > pick any merge strategy, as it doesn`t really make much sense. If you > > do want a specific strategy, than that`s _recreating_ a merge, and it > > goes fine with what you already have for `--recreate-merges`. > > > > On merge rebasing, the underlying strategy we decide to use is just an > > implementation detail, picking the one that works best (or the only > > one that works, even), user should have nothing to do with it. > > Just to add, if not already assumable, that I think we should stop > and let user react on conflicts on each of the "rebase the original > commit" strategy steps (rebase first parent, rebase second parent... > merge parents). I am not sure about that. Actually, I am pretty certain that we should imitate the recursive merge, which "accumulates" merge conflicts and only presents the final result, possibly with nested merge conflicts. In practice, we see that rarely, and more often than not, in those cases the user wants to re-do the merge differently, anyway. In the scenario we discuss here, I would wager a bet that the user encountering nested merge conflicts would most likely see that the rebase tried to rebase a merge, then `git reset --hard` and re-do the merge manually (i.e. *recreate* rather than *rebase*, most likely with (non-nested) merge conflicts). > I guess this stresses not using real "octopus merge" strategy even in > case where we`re rebasing octopus merge commit even more (and aligns > nicely with what you seem to expect already). My mistake, I should have pointed you my implementation: https://github.com/git/git/commit/d41a29ceb61ff445efd0f97a836f381de57c5a41 The full thicket of branches can be found here: https://github.com/git/git/compare/master...dscho:sequencer-shears I chose to make this an add-on patch after adding support for octopus merges because it actually makes it easier to think about "rebase merge commits" independently of the number of merge parents. Ciao, Dscho
