Re: Current state / standard advice for rebasing merges without information loss/re-entry?

[Sergey Organov <sorganov@gmail.com>]

Martin von Zweigbergk <martinvonz@gmail.com> writes:

> On Tue, Apr 19, 2022 at 5:25 AM Sergey Organov <sorganov@gmail.com> wrote:
>>

[...]

>> so I'd still propose to
>> *rebase* merge *commits* as *content*, without any additional info being
>> used, if at all possible.
>
> Rebasing is about applying changes from some commit onto some other
> commit, as I'm sure you know.

Yep.

> What Elijah and I are proposing is to
> consider the changes in the commit to be relative to the auto-merged
> parents (regardless of the number of parents - auto-merging a single
> parent commit just yields that commit), although I don't think Elijah
> phrased it that way.

I admit I didn't put enough thought into this new (to me) idea, but I
can't immediately see advantages of this method. Suppose, for the sake
of the argument, that the merge commit in question has been created
without any use of an auto-merge (whatever it actually means) in the
first place. What's then the reason to consider it to be a diff with
respect to an auto-merge? What advantages would it bring?

Then, do we need to be able to reproduce that exact auto-merge in 2
years from now for the method to work reliably? If so, isn't it a
problem, as we seem to agree that merge algorithms are subject to change
over time?

Essentially, this method apparently still puts a result of particular
procedure at the root of the method, again mixing merge-a-process with
merge-commit-the-result, that to me looks fundamentally flawed. I still
think that at its core Git should remain indifferent to the way a commit
has been created, be it merge or non-merge.

OTOH, the method of rebasing merge commits I've described long ago has
no assumptions about procedures involved in creation of the commit to be
rebased, nor does it need any notion of conflicts being involved in the
process, if any. It simply doesn't care, exactly the same way current
rebase doesn't care, when it rebases non-merge commits, if they were
created, say, using conflicting cherry-picks. What it cares about is
preserving the content by properly applying the recorded changes to the
new base. This property of the method I've suggested makes me believe it
is the best candidate for the core functionality, on top of which other
usable features could evolve.

Anyway, the choice is up to whoever gets time and desire to implement
it, and, not being that guy for now, I'm only looking forward for any
suitable solution for reliable rebasing of merge commits.

Thanks,
-- Sergey Organov