I like to have an option for 'darcs pull' that allows to pull in patches 
from elsewhere without touching the working tree.


Motivation

It happens occasionally that I make changes to a working tree that should 
be better split into several patches. However, I want to prepare patches 
that are consistent. Thus, say I have repository A with many changes that 
are too many for one patch. Now I create a repository clone B and transfer 
selected changes from A's working tree to B ones using a tool like 'meld' 
until B reaches a consistent state (i.e. can be compiled and tested 
successfully). Now I record a new patch in B. I go back to A and try 
"darcs pull ../B". But this will cause a lot of conflicts with A's working 
tree. However I do not want merging with A's working tree because it is 
already in a consistent state. Thus I'd prefer to do "darcs pull 
--keep-working ../B".


Workaround

Here is what I currently do instead: I create another working copy that 
shares the patches with A using a symbolic link:

$ mkdir A_shadow
$ cd A_shadow
A_shadow$ ln -s ../A/_darcs
A_shadow$ darcs revert -a
A_shadow$ darcs pull ../B

An ugly hack, isn't it?


Extension

Other commands like apply, push, rebase suspend/unsuspend would benefit 
from this option, too. The existing command 'unrecord' could actually be 
defined as 'obliterate --keep-working'.

Interesting idea. I agree it would be useful. And also not hard to 
implement, we merely need to guard against the flag when we do the 
final applyToWorking (or pass the option to that procedure).

Question: what to do with pending?

I guess the proposed name of the option was somewhat tongue-in-
cheek, my choice would be --no-apply-to-working. (The shorter --no-
apply would be fine except that `darcs apply --no-apply` looks 
confusing.)

To answer my own question, the behavior wrt unrecorded changes, 
including the pending patch, should be exactly as with record, 
reflecting the intended use case (i.e. behave as if we recorded the 
patches here).