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 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).
