[Feature Request] "partial" or "hybrid" rebasing to resolve conflicts

[claytonrcarter]

Problem

When working w/ a large stack of commits¹ and updating something early in the stack, in-memory rebases may fail due to a conflict later in the stack. Even if only 1 commit needs the on-disk rebase, we have to opt out of fast, in memory rebasing and do the entire rebase on disk. In a large stack (and on ageing, overworked hardware *ahem*) this can be very slow.

Request

One possible solution is to consider "partial" or "hybrid" rebases:

1. attempt the in-memory rebase, applying all commits up to the first that caused the conflict
2. trigger an on-disk rebase (or cherry pick) for the conflicting commit
3. resolve conflicts manually and continue
4. go back to step 1, but only for the remaining commits

Footnotes

1. Yes, I know, this is an antipattern in itself, yet here I am. And, yes, I know that jj obviates this entire situation. 😝 ↩

[arxanas]

It would be nice, but it's indeed a lot of complexity 😅. A related workflow is rebasing to "as recent" of a commit as possible without causing conflicts in the stack.