[darcs-users] darcs patch: Resolve issue1588: make--dont-allow-conflicts filter ...
dan at ag-projects.com
Mon Oct 5 13:10:10 UTC 2009
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
>> 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
> Did you mean to say "mutually exclusive" rather than "orthogonal"
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
> 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,
> --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
> 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
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
> likely use cases are for the user to specify --mark-conflicts or
> --don't-allow-conflicts in the defaults file, and then to override
> 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
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).
More information about the darcs-users