-----BEGIN PGP SIGNED MESSAGE-----
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.
ok
> 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
v
darcs unpull --match "just pulled"
(this needs to be added, but seems worthwhile to have)
versus
darcs pull --> is conflict manageable? -yes-> merge --> hack away
|
no
v
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
[snip]
> 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.
Florent
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkz+PqMACgkQTCPcDztjGo5hWgCghMrKOU1ZbMBJ7I8yfs4zBXH3
pQkAnAz5CJgQxJEwz6Swcx7hC8n/N4HI
=wi/t
-----END PGP SIGNATURE-----
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
