On 5 Oct 2009, at 00:23, Eric Kow wrote:
It sounds fairly reasonable to me to expect that people generally are
not going to put --skip-conflicts in their defaults, and also to treat
conflict choice as orthogonal to conflict resolution.
Seems fairly reasonable, until some user finds a use for it :).
Besides you should be able to handle the situation, as the user is
allowed to create it. I would even find it weird if some sibling
options are allowed on the defaults file, but some other are only
allowed on the command line.
--mark-conflicts
and friends would have no effect when --skip-conflicts is around, but
those not seem like a problem since --skip-conflicts is stronger
anyway.
My opinion is that developers should put the user hat on and try to
see this from the user perspective. If these 4 options controlling how
conflicts are to be handled, are not mutually exclusive but have
varying particular effects on each other, it will make it hard for
users to remember their relationships and what is even harder is to
remember what options were put where, in order to try to mentally
compute what the result of the command one types will be.
I know of a similar case which I find to be very confusing: I define
the external-merge options in the darcs defaults file and I do not use
any of the options that control how the conflict is handled in the
defaults file. The if I use darcs pull --dont-allow-conflicts and
there is a conflict I still get the program that I defined as external-
merge to run and it acts as if the --mark-conflicts was in effect.
Now I know that mark-conflicts is the default, but if I specify --dont-
allow-conflicts on the command line, I expect it to do exactly that,
not to use mark-conflict because somehow external-merge options in
some defaults file depends on that and enforces it no matter what I
say on the command line.
This kind of behavior is both unexpected and confusing to users, so
the simpler we keep it (in this case make them mutually exclusive and
take the last option) the easier will be to use them.
--
Dan
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
