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

Hi Buga,

On Tue, 13 Mar 2018, Igor Djordjevic wrote:

On 12/03/2018 11:46, Johannes Schindelin wrote:

quoted

quoted

Sometimes one just needs to read the manual, and I don`t really
think this is a ton complicated, but just something we didn`t really
have before (real merge rebasing), so it requires a moment to grasp
the concept.

If that were the case, we would not keep getting bug reports about
--preserve-merges failing to reorder patches.

Not sure where that is heading to, but what I`m arguing about is that 
introducing new commands and concepts (`merge`, and with `-R`) just 
makes the situation even worse (more stuff to grasp).

The problem with re-using `pick` is that its concept does not apply to
merges. The cherry-pick of a non-merge commit is well-defined: the current
HEAD is implicitly chosen as the cherry-picked commit's (single) parent
commit. There is no ambiguity here.

But for merge commits, we need to specify the parent commits (apart from
the first one) *explicitly*. There was no need for that in the `pick`
command, nor in the concept of a cherry-pick.

Reusing existing concepts where possible doesn`t have this problem.

Existing concepts are great. As long as they fit the requirements of the
new scenarios. In this case, `pick` does *not* fit the requirement of
"rebase a merge commit".

If you really want to force the `pick` concept onto the use case where you
need to "reapply" merges, then the closest you get really is Sergey's
idea, which I came to reject when considering its practical implications.

Even so, you would have to make the `pick` command more complicated to
support merge commits. And whatever you would do to extend the `pick`
command would *not make any sense* to the current use case of the `pick`
command.

The real problem, of course, is that a non-merge commit, when viewed from
the perspective of the changes it introduced, is a very different beast
than a merge commit: it does not need to reconcile changes, ever, because
there is really only one "patch" to one revision. That is very different
from a merge commit, whose changes can even disagree with one another (and
in fact be resolved with changes disagreeing *yet again*)!

quoted

quoted

Saying in favor of `--rebase-merges`, you mean as a separate option,
alongside `--recreate-merges` (once that series lands)?

No. I am against yet another option. The only reason I pollute the
option name space further with --recreate-merges is that it would be
confusing to users if the new mode was called --preserve-merges=v2
(but work *totally differently*).

I see. So I take you`re thinking about renaming `--recreate-merges` to
`--rebase-merges` instead?

Thinking about it. Nothing will happen before v2.17.0 on that front,
though, because -- unlike you gentle people -- I have to focus on
stabilizing Git's code base now.

That would seem sensible, too, I think, being the default usage mode in
the first place. Being able to actually (re)create merges, too, once
user goes interactive, would be "just" an additional (nice and powerful)
feature on top of it.

The implementation detail is, of course, that I will introduce this with
the technically-simpler strategy: always recreating merge commits with the
recursive strategy. A follow-up patch series will add support for rebasing
merge commits, and then use it by default.

This latter part will need a lot of experimentation, though. That's why I
want the --recreate-merges patch series cooking in `next` first.

Ciao,
Dscho