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 email@example.com:screened:
Author: Ganesh Sittampalam <firstname.lastname@example.org>
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
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.