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

Jacob Keller [off-list ref] writes:

On Tue, Mar 27, 2018 at 10:57 PM, Sergey Organov [off-list ref] wrote:

quoted

Hi Johannes,

Johannes Schindelin [off-list ref] writes:

[...]

I'm pretty sure the fact has already been accepted, as he did indeed
implement and develop a strategy for rebasing the merges (Phillip's
strategy). He hasn't chosen to re-write all the code such that it was
"always" this method, but rather kept it as an incremental patch on top as
it makes it easier to review the changes since we've already spent time
looking at and reviewing the --recreate-merges patches.

That's perfectly OK with me, except that he apparently still can't
accept the fact that rebasing a non-merge is not fundamentally different
from rebasing a merge.

"Rebase non-merge" is just a special case of generic "rebase commit",
provided we do have generic method that is capable to rebase any commit,
and we do have it, Phillip's or not.

Having watched from the sidelines, I've been unable to completely
understand and parse the strategies completely, but I've also found
Phillip's method to be easier to understand.

It doesn't matter at all for this particular discussion. Let's call the
method "rebase a commit", a black-box, that is capable to rebase any
commit. I don't care what implementation is inside. Rebasing a commit is
still rebasing a commit, and it should not be called "merge" in the todo
list.

As someone who's read the discussion on the sidelines, it certainly
does feel like there is some misunderstanding on both sides. Neither
of you have been able to get the other to see what you clearly both
believe strongly.

Calling "rebase" operation "merge" is wrong no matter what method is
used to rebase a commit. Isn't it obvious? It's currently called "pick"
in the todo and it seems natural to continue to use that name for
picking a commit, whatever number of parents it happens to have.

Unfortunately I do not have any suggestion as to how to resolve the
misunderstanding.

This sub-thread is not about method at all, so no resolution on that
matter is required here. This sub-thread is about todo format only.

Sergey's method appears to me to be more complex, and I agree that the
extra steps could cause more merge conflicts, at least in how it was
originally conceptualized and implemented. It is possible that we are
mis-understanding the terminology for U1 and U2? It sure seems like it
introduces more changes for merge conflicts than the strategy proposed by
Phillip. However, the latest editions also sound a lot closer to Phillip's
strategy in general, so maybe I have mis-understood how it works and what
is fundamentally different about the two strategies.

There is nothing fundamentally different between them and thus I don't
care in this discussion what exact method is being used.

-- Sergey