Hi Phillip and Johannes, On 08/03/2018 12:20, Phillip Wood wrote: > > I did wonder about using 'pick <original-merge>' for rebasing merges and > keeping 'merge ...' for recreating them but I'm not sure if that is a > good idea. It has the advantage that the user cannot specify the wrong > parents for the merge to be rebased as 'git rebase' would work out if > the parents have been rebased, but maybe it's a bit magical to use pick > for merge commits. Also there isn't such a simple way for the user to go > from 'rabase this merge' to 'recreate this merge' as they'd have to > write the whole merge line themselves (though I guess something like > emacs' git-rebase.el would be able to help with that) Hmm, funny enough, `pick <original merge>` was something I though about originally, too, feeling that it might make more sense in terms on what`s really going on, but I guess I wanted it incorporated into `--recreate-merges` too much that I tried really hard to fit it in, without changing it much :/ And now that I said this in a previous reply: > 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 underline 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. The difference between "rebase merge commit" and "recreate merge commit" might starting to be more evident. So... I might actually go for this one now. And (trying to stick with explicit mappings, still :P), now that we`re not married to `merge` expectations a user may already have, maybe a format like this: pick <original-merge> <original-parent1>:HEAD <original-parent2>:<new-parent2> Here, original-merge is a _commit_, where original-parent and new-parent are _labels_ (in terms of `--recreate-merges`). Everything else I previously said still holds - one is allowed to change or drop mappings, and add or drop new merge parents. Yes, in case user does something "stupid", he`ll get a lot of conflicts, but hey, we shouldn`t judge. p.s. Are we moving towards `--rebase-merges` I mentioned in that other topic[1], as an add-on series after `--recreate-merges` hits the mainstream (as-is)...? :P Regards, Buga [1] https://public-inbox.org/git/bc9f82fb-fd18-ee45-36a4-921a1381b32e@xxxxxxxxx/
