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.
