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

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

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