Hi Buga, On Thu, 8 Mar 2018, Igor Djordjevic wrote: > On 08/03/2018 13:16, 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) > > > > Scrub that, it is too magical and I don't think it would work with > > rearranged commits - it's making the --preserve-merges mistake all > > over again. It's a shame to have 'merge' mean 'recreate the merge' and > > 'rebase the merge' but I don't think there is an easy way round that. > > I actually like `pick` for _rebasing_ merge commits, as `pick` is > already used for rebasing non-merge commits, too, so it feels natural. Phillip is right, though: this would repeat the design mistake of --preserve-merges. We must not forget that the interactive mode is the target here, and that the syntax (as well as the generated todo list) must allow for easy modification. The `pick <merge>` approach does not allow that, so we cannot use it. The `merge -R -C <original-commit> <merge-head>` approach is a lot better: it offers the flexibility, without sacrificing the ease when not modifying the todo list. Ciao, Dscho
