Re: [RFC PATCH] rebase: implement --rewind

[Oswald Buddenhagen <oswald.buddenhagen@gmx.de>]

On Wed, Apr 05, 2023 at 02:07:29PM +0200, Johannes Schindelin wrote:
>This question brings me back to the initial question: What problem do 
>we try to solve here? (This is a question that try as I might, I cannot 
>see answered in the proposed commit message.)
>
and i, try as i might, don't understand what you're not understanding 
...

>[...] In other words, I need a nested rebase.
>
that's just *your* private terminology. i don't apply the term "nested" 
here, because for me that implies the possibility to "unnest", which my 
patch doesn't implement. instead, it just continues past the point where 
the rewind was initiated. it's the difference between a loop and 
recursion.
but outside this difference in terminology, for all i can tell, my patch 
implements *exactly* what you're asking for, and i don't understand why 
that's not obvious to you, given how well you understand the problem 
space yourself.
please describe what you want with _a few_ words and without introducing 
any new terminology first, i.e., something you'd actually want to see in 
the feature's summary documentation. that should illuminate what 
keywords you find critical.

i just gave rewinding rebasing merges a shot, and it didn't work for the 
simple reason that --rebase-merges is not saved in the state 
(understandably, because that was unnecessary so far) and the 
combination of --rewind --rebase-merges is being rejected. i'll need to 
fix that.

then there is the problem that --rebase-merges only redoes merges rather 
than replaying them. but it seems that the simple case with unmodified 
parents actually does get replayed (or rather, skipped over, just 
incredibly slowly), so rewinding to just the last merge would work fine.  
other than that, i'm declaring the matter out of scope and deferring to 
your "replaying evil merges" sub-thread.