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
_______________________________________________
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users
