This lifts a limitation that has annoyed me ever since I started using
rebase regularly. Interestingly, the same annoying limitation exists in git;
I wouldn't dream of trying to fix it there.

The patch depends on two cleanup/refactor patches which are therefore
included.

3 patches for repository http://darcs.net/screened:

patch 926216a7c734b0e7fd8d0e6be324370ded4b86c4
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Mar  2 19:48:10 CET 2021
  * refactor rebase unsuspend

  The local function hijack that replaces the previous doAdd is more modular.
  It gets the selected suspended patches and those we want to keep as input
  and outputs a changed pair where the the patches to be unsuspended have been
  renamed. We then add these patches to the repo without updating the pending
  patch, so we can afterwards directly set pending to the resolution.

  For reasons that are mysterious to me, coercing just the added renames after
  commuting them no longer works; the mere act of matching the type of the
  rename patch introduces a fresh type variable for the underlying patch type.

patch ec5b78a3a97dcf6254b643faa5553b87e1e31f7a
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Mar  2 19:56:13 CET 2021
  * rebase unsuspend: code layout and a few renamings

patch 92530babc63f56638b73a94bc9c8279c96324d1e
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Mar  2 21:52:15 CET 2021
  * allow rebase unsuspend when there are unrecorded changes

  We still fail if the effect of the unsuspended patches (including the
  resolution for any residual fixups) conflicts with unrecorded.

Attachments

• patch-preview.txt
• refactor-rebase-unsuspend.dpatch

More precisely, what git doesn't allow is to start a rebase when there 
are unrecorded changes, while darcs allowed to start it (suspend) but 
not to finish it (unsuspend).