1 patch for repository http://darcs.net/screened:

patch 8ab79ef63079d445c23ac9bbc037fcd117e12404
Author: Ben Franksen <ben.franksen@online.de>
Date:   Sun Feb 26 21:00:41 CET 2023
  * resolve issue2699: obliterate and rebase suspend fail to adapt pending

  This is a rollback of

  patch 4f9ac2caf52b420538798dddc15f4211c1fdcaa8
  Author: Ben Franksen <ben.franksen@online.de>
  Date:   Tue Mar  2 14:13:40 CET 2021
    * obliterate, rebase suspend: pass NoUpdatePending to
    tentativelyRemovePatches

  though adapted to the changes made in

  patch 8237940978023934f829ef3d5d449007b867d55f
  Author: Ben Franksen <ben.franksen@online.de>
  Date:   Tue Mar  2 16:06:25 CET 2021
    * remove the unsafe tentativelyAddToPending, replace with addToPending

  When we remove patches from the repo and the working tree (as done in
  obliterate and rebase suspend), we must also adapt the pending patch. The
  way this was (and is now again) done is by first prepending the effect of
  the removed patches to pending (by passing YesUpdatePending to
  tentativelyRemovePatches). Afterwards we append the inverse of the result of
  commuting this effect with all unrecorded changes at the end of the working
  state. The net effect of these two operations on the working tree is Nil,
  but their effect on the pending patch is not, since the effect of the
  removed patches gets commuted through pending when pending is sifted.

  This is a very roundabout way to adapt pending. It would be simpler to just
  commute pending through the effect of the removed patches and directly store
  the result.

Attachments

• patch-preview.txt
• resolve-issue2699_-obliterate-and-rebase-suspend-fail-to-adapt-pending.dpatch

Looks fine (as with other repository state patches I don't understand
well enough to really be independently sure)

For the record: The change I suggested at the end of the long comment, namely

> This is a very roundabout way to adapt pending. It would be simpler to just
> commute pending through the effect of the removed patches and directly store
> the result.

has been made as part of the following two patches (both in screened):

  * rebase: offer to revert conflicting unrecorded changes
  * obliterate: offer to revert conflicting unrecorded changes (if any)

I failed to mention this is in their descriptions (and the tickets) because they 
actually pre-date this fix and were rebased afterwards (because I didn't want to 
conflate a new feature with a bugfix).