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.
