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

Florent Becker florent.becker at ens-lyon.org
Tue Dec 7 14:03:15 UTC 2010

Hash: SHA1

Hi Dan,

thanks for your feedback.
>> 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. 

Ok, let's see how to reduce the annoyance in the second case (so that
you can the advantage of being able to go back to pre-conflicting state).

> I darcs record.

This can and should be automated at the point where you darcs pull, with
good default patch info, as we assume that you're going to amend it later.
> 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).
You'd still have to unrecord if you want to do that. The other solution
is to have darcs whatsnew take a --from-{p,m}atch argument, like darcs
diff, so that you can say darcs whatsnew --from-patch "CONFLICT
AUTO-BACKUP". Incident question: shouldn't we merge diff and whatsnew,
with darcs whatsnew being an alias for "darcs diff --darcs-format"?

So your workflow would be:

darcs pull --> is conflict manageable? -yes-> merge --> unrecord -+
                    |                                             v
                    no                                       hack away
                  darcs unpull --match "just pulled"
                  (this needs to be added, but seems worthwhile to have)


darcs pull --> is conflict manageable? -yes-> merge --> hack away
                 game over

Where the upper unrecord would not be necessary if commands like
whatsnew are made aware of auto-recorded patches (I'm not sure if such
special treatment is elegant, though).
>>> 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


> 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.
This means the force/no-force should be independant of conflicts.

The way I see it (renaming --force into --allow-unrecorded-changes):
- -with --allow-unrecorded-changes: current behaviour
- -without it (ie, --no-allow-unrecorded-changes): if you have unrecorded
changes, stop before offering patches to pull, then proceed as usual. Or
offer to auto-record the changes, then proceed as usual, as above.

Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the darcs-users mailing list