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

patch 25ec55da61a62b5877a1ed726cc970a56374bccf
Author: Ben Franksen <ben.franksen@online.de>
Date:   Mon Jul  2 15:14:09 CEST 2018
  * rename UpdateWorking to UpdatePending
  
  The name of this type (and the parameter names) now reflect what it does,
  namely configure for certain calls whether the pending patch should be
  updated or not.

patch a7c4c26ac2e18d179157ef21f8decd172b28c741
Author: Ben Franksen <ben.franksen@online.de>
Date:   Mon Jul  2 15:15:36 CEST 2018
  * removed UpdatePending parameter from a few functions
  
  Affected are setTentativePending, prepend, the functions in D.R.Merge,
  addToPending, and addPendingDiffToPending. The parameter could be removed
  because either all call sites passed YesUpdatePending (literally), or the
  same or closely related case distinction was already done at the call
site.

patch 043bfc4fa2c2d6041123c9304248cffcfdccbb2c
Author: Ben Franksen <ben.franksen@online.de>
Date:   Mon Jul  2 16:18:14 CEST 2018
  * add revertPending to complement finalizePending

patch 924eda6c399111296dc3983c78f6d1bd0ade8588
Author: Ben Franksen <ben.franksen@online.de>
Date:   Mon Jul  2 16:34:03 CEST 2018
  * remove UpdatePending parameter from tentativelyAddToPending
  
  All call sites passed YesUpdatePending, literally.

Attachments

• rename-updateworking-to-updatepending.dpatch

Looks fine. So does our code that updates the working tree always just 
do it unconditionally?

Whether the working tree should be updated is decided at a higher layer.
For instance, tentativelyMergePatches does not itself touch the working
tree, instead it returns the patches it would apply to it and the
commands explicitly apply these patches.