[darcs-users] [issue2011] refuse to pull/apply patches if you have unrecorded changes

Dan Pascu dan at ag-projects.com
Tue Dec 7 13:34:04 UTC 2010

On 7 Dec 2010, at 00:39, Ganesh Sittampalam wrote:

> Hi Dan,
> On Mon, 6 Dec 2010, Dan Pascu wrote:
>> I just noticed this thread, but I disagree with everything proposed  
>> thus far. In my workflow I found that it is much better to pull a  
>> patch that conflicts over an unrecorded change than over a recorded  
>> one. In the former case I just fix the conflict in my working files  
>> and then I record a patch that has no conflict. In the other case  
>> (pulling over recorded patches) I will end up with a conflict that  
>> I need to solve by recording a conflict resolution patch.
> Instead of recording a fresh conflict resolution, you can always  
> amend-record the local patch. This is equivalent to what you'd get  
> if you pulled with unrecorded changes, resolved, then recorded  
> (modulo some very occasionally differences in hunk alignment that  
> can arise between record;amend-record versus unrecord;record, but  
> these are rare and unlikely to be important even when they happen.)

Except that is a lot more complicated. Consider the case where I'm  
working on something, but I need some bug fixes someone else made:

1. I darcs pull, solve conflicts in something like k3diff and keep  
working on my code


2. I darcs record. then I darcs pull and fix the conflict. then I  
darcs amend-record. then I darcs unrecord in order to continue  
working. (or after fixing the conflict I just darcs unrecord and skip  
amend-record. or I keep just using amend-record to update my work, but  
this is not nice as I can't see the global diff while I work when some  
work is recorded while some is not).

>> So refusing to pull a patch because it conflicts with my working  
>> files would be a major let down in my case. Even if darcs would  
>> record a temporary draft patch which I could unrecord later and  
>> keep my workflow that avoids the conflict, it'll still make life  
>> much more complicated than necessary.
> A --force option is being proposed, so you could always put that in  
> your defaults.

If this proposal goes through, then a --force option would definitely  
be very useful, but it will also be a bit confusing from a UI  
perspective. We already have --allow-conflicts, --dont-allow-conflicts  
and --mark-conflicts

Now we will have:

--allow-conflicts which will actually not allow conflicts if there are  
unrecorded changes (confusing)
--allow-conflicts --force which will allow conflicts no matter what

we will also have things like:

--dont-allow-conflicts --force which makes no sense whatsoever, but it  
needs to be supported in order to be able to set the force options in  
the defaults file for pull.

In other words the existing options that deal with allowing/denying/ 
marking conflicts have lost their original meaning as they are now  
dependent on the --force option. Which takes 3 clear options and makes  
them into a matrix of 6 option combinations that is hard to comprehend.


More information about the darcs-users mailing list