Issue 2675 darcs pull --keep-working

Title darcs pull --keep-working
Priority feature Status needs-implementation
Milestone Resolved in
Superseder Nosy List lemming
Assigned To

Created on 2021-03-15.08:35:14 by lemming, last changed 2023-07-16.16:30:11 by bfrk.

msg22656 (view) Author: lemming Date: 2021-03-15.08:35:12
I like to have an option for 'darcs pull' that allows to pull in patches 
from elsewhere without touching the working tree.


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".


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?


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'.
msg22966 (view) Author: bfrk Date: 2022-04-12.13:07:16
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?
msg23594 (view) Author: bfrk Date: 2023-07-16.16:30:10
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 

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).
Date User Action Args
2021-03-15 08:35:14lemmingcreate
2022-04-12 13:07:17bfrksetstatus: unknown -> needs-implementation
priority: feature
messages: + msg22966
2023-07-16 16:30:11bfrksetmessages: + msg23594