Hi Oswald,

On Thu, 23 Mar 2023, Oswald Buddenhagen wrote:

This is fundamentally --edit-todo, except that we first prepend the
already applied commits and reset back to `onto`. This is useful when
one finds that a prior change needs (further) modifications.

This patch implements "flat" rewind, that is, once the todo edit has
been committed, one can abort only the complete rebase. The pre-rewind
position is marked with a `break` command (these pile up when rewinding
multiple times; the user is expected to clean them up as necessary).

An alternative to that would be "nested" rewind, where one can return to
the pre-rewind state even after committing the todo edit. However, this:
- would add somewhat significant complexity due to having to maintain a
  stack of todos and HEADs
- would be mildly confusing to use due to needing to track the state of
  the stack. One could simplify this somewhat by hiding the rest of the
  previous todo before nesting, but this would be somewhat limiting in
  turn (one might want to defer a factored out hunk, and stashing it is
  not necessarily the most elegant way to do it).
- would be of somewhat limited usefulness, speaking from experience

This patch leaves transitive resolution of rewritten-list to the
consumer. This is probably a bad idea.
Somewhat related to that, --update-refs isn't properly handled yet.

This is an interesting idea but I do not think that the concept in its
current form mixes well with being in the middle of a `--rebase-merges`
run. Which is what I would want to see supported because I find myself
wishing for _something_ like this [*1*].

On the other hand, it might often be good enough to redo only the commits
between `onto` and `HEAD`, not the complete rebase script that's now in
`done`. But then it does not strike me so much as "rewinding" but as
"nesting.

In other words, I would then prefer to see support for `git rebase -i
--nested` be added. I wrote up my thoughts about this in
https://github.com/gitgitgadget/git/issues/211 and was tempted several
times to start implementing it already, only for other, more pressing
things to come up and take my attention.

What do you think, would you be amenable to combine efforts?

Ciao,
Johannes

Footnote *1*: I usually find myself adding a temporary worktree with a
detached `HEAD`, performing the nested rebase, and then resetting the
original worktree to the output of `rev-parse HEAD` in the temporary
worktree. Cumbersome, yes, and it works, but yes, I dearly want something
that works without requiring _me_ to keep tabs on the state.