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

From: Sergey Organov <sorganov@gmail.com>
Date: Apr 18, 2022, 16:47 UTC
Message-ID: <87h76qwd8a.fsf@osv.gnss.ru>
In-Reply-To: <CAPMMpojjs4sjKdN6DAJFSwERdjq9XQgi35CcqkXu7HijadHa1Q@mail.gmail.com>

Tao Klerks <tao@klerks.biz> writes:

Show 6 quoted lines

> Hi folks,
>
> The discussion around Edmundo Carmona Antoranz's recent "git replay"
> proposal ([1]) led me down a rabbit-hole reminding me I really don't
> understand where we stand with rebasing merges, and I don't think I'm
> alone.

Neither do I. Status-quo seems to be sub-optimal, or worse. I, personally, still use 2-step merge workflow, see below.

Show 15 quoted lines

>
> I understand the standard advice at the moment to be something like:
> ---
> Use a recent git client, use the '--rebase-merges' option (avoid the
> --preserve-merges option if you find it), and re-resolve any textual
> and/or semantic conflicts manually (possibly using rerere if you know
> what you're doing).
> ---
> Is this correct?
>
> This current state/advice seems... suboptimal, at best, because it
> ignores any information encoded in the original merge commit, as
> clearly documented in the help. It will often result in you having to
> resolve conflicts that you already resolved, *where nothing relevant
> to that merge/commit has changed in your rebase*.

This is IMHO the least important of 2 drawbacks of this method. The most important one is that it silently drops user changes, that is major deficiency that, e.g., forces me to split my merges into 2 commits: the merge itself (along with formal conflict resolutions) and the semantic fixes to the merge needed by the project. This is constant headache.

[...]

The above deficiency was the main reason of the:

Show 7 quoted lines

> Similarly, Sergey Organov refers to a thread/discussion four years ago
> [3], largely involving a debate around two implementations (his and
> that of Phillip Wood?) that are largely theoretically-equivalent (in a
> majority of cases), with a lovely explanation of the theory behind the
> proposal by Igor Djordjevic / Buga [4], but that discussion appears to
> have dried up; I can't tell whether anything came of it, even if only
> a manually-usable "rebase a merge" script.

I still hope rebase will finally start to rebase *all* commits, at least by default, rather than trying to re-create (some of) them out of thin air.

I'd love to implement that myself, but unfortunately it won't happen any time soon, sorry.

Show 7 quoted lines

> Finally, Martin von Zweigbergk mentions his git-like VCS [5] which
> stores conflict data in some kinds of commit as part of a general
> "working state is always committable and auto-committed"
> state-management strategy; I may be misunderstanding something, but I
> *think* the resulting conflict-resolution information ends up being
> reusable in a manner theoretically equivalent to the strategy
> described by Buga as referenced above.

I still think that Git got it right by *not* storing things like that (e.g., renaming paths / moving contents), so I'd still propose to *rebase* merge *commits* as *content*, without any additional info being used, if at all possible. As I wrote in the aforementioned discussion, we should not confuse "merge-the-process" and "merge-the-result". It's the latter, the commit, that should be rebased no matter what particular process has been used to get to this commit, in accordance with general Git philosophy.

Besides, merge algorithms themselves are subjects to change, so a merge performed 2 years ago might end-up being rather different when attempted with a new algorithm today, rendering information stored from an old algorithm useless.

That said, I'm not opposed to storing/using additional merge meta-information in general, but it should be an *option* rather than a requirement, to only improve otherwise reliable content rebasing algorithms.

Thanks, -- Sergey Organov