Patch 2020 rebase unsuspend: start at the beginning when extracting

Title rebase unsuspend: start at the beginning when extracting
Superseder Nosy List ganesh
Related Issues
Status accepted Assigned To

Created on 2020-05-09.16:38:24 by ganesh, last changed 2020-07-22.08:55:49 by bf.

File name Status Uploaded Type Edit Remove
patch-preview.txt ganesh, 2020-05-09.16:38:22 text/x-darcs-patch
rebase-unsuspend_-start-at-the-beginning-when-extracting.dpatch ganesh, 2020-05-09.16:38:22 application/x-darcs-patch
unnamed ganesh, 2020-05-09.16:38:22 text/plain
See mailing list archives for discussion on individual patches.
msg22015 (view) Author: ganesh Date: 2020-05-09.16:38:22
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
msg22016 (view) Author: bf Date: 2020-05-10.10:26:55
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.
msg22017 (view) Author: ganesh Date: 2020-05-10.16:41:42
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.
msg22234 (view) Author: ganesh Date: 2020-07-21.21:38:50
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.
msg22240 (view) Author: bf Date: 2020-07-21.22:15:04
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.
msg22243 (view) Author: bf Date: 2020-07-22.08:55:49
A few more (failing) tests could probably be pulled from the abandoned
'rebase with conflicted fixups' branch.
Date User Action Args
2020-05-09 16:38:24ganeshcreate
2020-05-09 16:38:50ganeshsetstatus: needs-screening -> in-discussion
2020-05-10 10:26:56bfsetmessages: + msg22016
2020-05-10 16:41:43ganeshsetmessages: + msg22017
2020-07-21 20:46:40ganeshsetstatus: in-discussion -> needs-screening
2020-07-21 21:38:50ganeshsetstatus: needs-screening -> needs-review
messages: + msg22234
2020-07-21 22:15:05bfsetstatus: needs-review -> accepted-pending-tests
messages: + msg22240
2020-07-21 22:42:04bfsetstatus: accepted-pending-tests -> accepted
2020-07-22 08:55:49bfsetmessages: + msg22243