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

From: Martin von Zweigbergk <martinvonz@gmail.com>
Date: Apr 19, 2022, 04:24 UTC
Message-ID: <CANiSa6ipgk3dRJfOh6i1nL=QqtPTZ6n4ZheT+JowarMTOaeuDg@mail.gmail.com>
In-Reply-To: <CAPMMpojjs4sjKdN6DAJFSwERdjq9XQgi35CcqkXu7HijadHa1Q@mail.gmail.com>

On Mon, Apr 18, 2022 at 9:52 AM Tao Klerks <tao@klerks.biz> wrote:

Show 42 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.
>
> 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*. If you have rerere,
> and you know what you are doing, and you were the one that performed
> the merge, in this repo, then maybe you're ok; similarly if it's a
> clean merge of course.
>
> Elijah Newren describes this problem/opportunity quite carefully in
> [2], and mentions a bunch of WIP that I have a hard time getting my
> head around.
>
> 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.
>
> 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;

Just so there's no misunderstanding, the "auto-committed working copy" idea is not a requirement for storing conflict objects in trees.

> 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 think it's more similar to what Elijah suggested, actually. For example, my VCS lets you rebase a merge commit (the "evil" part of it) even if you don't rebase all its ancestors. Consider this case:

  X
 /
A---B---C
 \       \
  D---E---F

If you now want to rebase E onto X, and then F onto E' and C, then Elijah's suggestion (and what my VCS does) will work correctly. If I understood Sergey's proposal, on the other hand, the utility merge would bring in the changes from D as well. Or, put another way, that algorithm is only useful for rebasing "internal" merges, where the merge commit is being rebased along with both (all of) its legs (again, if I understood it correctly). With the "rebase changes compared to auto-merged parents" idea, you can even change the number of parents of a commit as you rebase it.

Show 48 quoted lines

>
> These kinds of discussions frequently seem to feature git experts
> saying "I have a script for my version of this problem" (Elijah,
> Junio, Johannes Schindelin, ...), or even "I have a VCS for this
> problem" :), but I seem to be too stupid or impatient to dig
> through/understand whether or when these things will work for a
> regular joe and how to use them.
>
> The temptation, obviously(?), is to write a "rebase a merge" script to
> do something like Sergey Organov's V2 proposal referenced above... but
> it feels like I'd be spending a bunch of time and ultimately just
> making things worse for the community, rather than better - helping
> myself based on my (very limited, but still above average)
> understanding of merge mechanics, in a way that leaves the general
> public message / status just as unsatisfactory/unhelpful.
>
> Does anyone have an existing simpler answer? Ideally I'm looking for
> something like:
> ---
> * When you have a merge in your history, and you are rebasing, follow
> steps XXXXXX, involving this publicly available gist, or contrib
> script, or experimental flag, and it will probably do what you want.
> If there is a (new) conflict when rebasing the merge commit, you can
> expect conflicts to be presented as YYYYY, because rebasing a merge in
> this "informed" way can fundamentally involve multiple different
> steps/phases of conflict resolution - rebase conflicts vs merge
> conflicts.
> * Something like this will likely be introduced as a new rebase option
> in a future release, something like "--reapply-merges", or
> "--rebase-merges-better", because it will always require the user to
> understand that the three-way conflicts presented as part of such an
> "informed" merge rebase are subtly different to regular rebase or
> merge conflicts.
> ---
>
> Is it possible to get that sort of simplistic message for this complex topic?
>
> My apologies if this request is a duplicate - obviously a pointer to
> some sort of existing summary would be perfect.
>
> Thanks,
> Tao
>
> [1]: https://lore.kernel.org/git/20220413164336.101390-1-eantoranz@gmail.com/
> [2]: https://lore.kernel.org/git/CABPp-BE=H-OcvGNJKm2zTvV3jEcUV0L=6W76ctpwOewZg56FKg@mail.gmail.com/
> [3]: https://public-inbox.org/git/87r2oxe3o1.fsf@javad.com/
> [4]: https://public-inbox.org/git/a0cc88d2-bfed-ce7b-1b3f-3c447d2b32da@gmail.com/
> [5]: https://github.com/martinvonz/jj