[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
vs
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)
and
--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.
--
Dan
More information about the darcs-users
mailing list