Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Buga,

On Thu, 8 Mar 2018, Igor Djordjevic wrote:

On 08/03/2018 13:16, Phillip Wood wrote:

quoted

quoted

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