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

From: Martin von Zweigbergk <martinvonz@gmail.com>
To: Sergey Organov <sorganov@gmail.com>
Cc: Tao Klerks <tao@klerks.biz>, git <git@vger.kernel.org>
Subject: Re: Current state / standard advice for rebasing merges without information loss/re-entry?
Date: Tue, 19 Apr 2022 08:24:21 -0700	[thread overview]
Message-ID: <CANiSa6jAjbPRii8GYYLzU88K9P-TG5GGBJGY-H1CwmPkb+yU-w@mail.gmail.com> (raw)
In-Reply-To: <87h76qwd8a.fsf@osv.gnss.ru>

On Tue, Apr 19, 2022 at 5:25 AM Sergey Organov <sorganov@gmail.com> wrote:
>
> Tao Klerks <tao@klerks.biz> writes:
>
> > 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),

My VCS doesn't store that either. Maybe you're thinking of Darcs or
Pijul? [1] explains what my VCS stores. FYI, [2] explains other
benefits of first-class conflicts; being able to rebase merge commits
is much less important than the other benefits, IMO (but it's still
important).

> 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. 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.

> 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.

I agree with all of that.

[1] https://github.com/martinvonz/jj/blob/main/docs/technical/conflicts.md
[2] https://github.com/martinvonz/jj/blob/main/docs/conflicts.md