As discussed in the thread "FullUnwind rebase behavior",
I think this change may sort out the problems with
unsuspending conflicts+their resolutions.

1 patch for repository darcs-unstable@darcs.net:screened:

patch 1a2d291109d8b59f4b8d623647341e7e15f1b834
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Sat May  9 17:38:28 BST 2020
  * rebase unsuspend: start at the beginning when extracting
  
  As the new comment explains, it's important to simplify any
  fixups that result from extracting the first patch, before
  extracting the next patch.
  
  As the associated test shows, this in particular makes
  unsuspending a conflict along with its resolution behave much
  better.

Attachments

• patch-preview.txt
• rebase-unsuspend_-start-at-the-beginning-when-extracting.dpatch
• unnamed

I applied this and tried to rebase the conflicts in patch2017. Indeed,
this is a big improvement. It does not solve the problem completely,
though: for some conflicts, unsuspending the patch and its resolution
still gives me conflicts, though not as often and not quite as
complicated as before. So there is still a case to be made for a 'darcs
rebase squash' command.

The plot thickens. I tried myself with patch2017, but accidentally
started out with a binary that didn't include this patch (patch2020).
Unsuspending all 33 patches at once didn't actually generate any conflicts,
though it did take a couple of minutes of CPU first.

Then I tried again with the correct binary that did include patch2020
and I got a few conflicts (in harness/Darcs/Test/Patch/Check.hs,
src/Darcs/Repository/State.hs and src/Darsc/UI/Commands/Unrecord.hs).

I'll keep playing with it, either experimenting with patch2017 or writing
some more testing infrastructure.

Screening this now after extensive discussion and experiments with
alternatives by Ben.

As per my earlier comment it's not unambiguously better but overall it seems
like the right thing to do. Still to is to document what kinds of situations
work well and what kinds don't, with test cases.

Looks good to me.

Regarding tests, we have at least rebase-conflict-resolution (added 
by this patch). On the negative side we have failing-rebase-
conflicting and failing-rebase-conflict-resolution3. This is far 
from perfect but I can't see a way to exactly specify what works and 
what does not.

Regarding docs for rebase: yes, badly needed. But out of scope for 
this bundle.

A few more (failing) tests could probably be pulled from the abandoned
'rebase with conflicted fixups' branch.