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