On 2 Oct 2009, at 15:33, Sittampalam, Ganesh wrote:
If that is so, I do not think it
would be the best choice. For example if I specify skip-conflicts in
the defaults file, but then I use --dont-allow-conflicts on the
command line, I expect the command line switch to take precedence
over whatever is specified in the defaults file, otherwise it will be
confusing.
I already reported a similar problem, where if I have mark-conflicts
in the defaults file but I use --dont-allow-conflicts on the command
line, the later is ignored; it may have been the other way around, I
don't remember exactly, however the point is that a command line
switch is ignored while the value from the defaults file is used,
which is confusing. The command line should always take precedence
over the defaults file. Also if multiple orthogonal switches are
specified on the command line, the usual practice is to use the last
one.
Did you mean to say "mutually exclusive" rather than "orthogonal"
here?
Yes, I did. Sorry for the inaccuracy.
In my opinion, for mutually exclusive options, you're certainly right
about picking the last option specified (with defaults implicitly
coming
before the command line).
However it's not completely obvious to me that --skip-conflicts really
is mutually exclusive with --don't-allow-conflicts. In particular,
with
--don't-allow-conflicts but not --skip-conflicts, you'll get offered
every patch and then get a failure if any conflict. So if we accept
your
argument, and you have --skip-conflicts as a default and then you
specify --don't-allow-conflicts on the command line, then suddenly
you'll get conflicting patches offered to you.
Why? Aren't the options selected (from global defaults, local defaults
and command line) before any processing is started? I do not know the
code, but I would expect that before any processing is done, the code
has already determined what options will be applied.
My general feeling is
that --skip-conflicts may not be that useful as a default, and the
more
It may not be useful, but you cannot stop someone from using it like
that and then you still have to handle the situation in the code in
order for the code to work in any possible case the user is allowed to
create.
likely use cases are for the user to specify --mark-conflicts or
--don't-allow-conflicts in the defaults file, and then to override
that
on the command line with --skip-conflicts.
OK, now I understand where you're coming from. However I do not agree
with this point of view. A darcs user doesn't know about all these
details and how the code is written and what dependencies are there in
the process of filtering out some patches. Making these options not
mutually-exclusive will make it very difficult for a user to remember
all the relations between them, which has to come first, which affects
which and how. Now even if he remembers that he would have to also
remember what options he put where (global defaults, local defaults)
and how they will combine with what he just typed on the command line.
This can get out of hand fast.
IMO, these options should not mix with each other. The last one
specified should take effect, the previous ones should be ignored.
This would make the user interface much cleaner, simpler to use and
remember.
I know that for a developer, these relations may be obvious or easy to
remember, but it would simplify it a lot of end users if it would be
restricted to a set of mutually exclusive options (which should be
easy to do by just picking the last one specified).
--
Dan
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
