[darcs-users] darcs patch: Resolve issue1588: make--dont-allow-conflicts filter ...
ganesh.sittampalam at credit-suisse.com
Mon Oct 5 13:28:29 UTC 2009
Dan Pascu wrote:
> On 2 Oct 2009, at 15:33, Sittampalam, Ganesh wrote:
>> 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.
It's not an issue of the code, but of the user interface (I know I
started out this discussion by explaining what the code would do by
default, but that's actually irrelevant since it's quite easy for me to
implement either option.)
With just --don't-allow-conflicts, conflicting patches are presented
during interactive selection, but selecting one causes a later failure.
With just --skip-conflicts, conflicting patches are not presented during
So if we say that they are mutually exclusive options, then
--skip-conflicts --don't-allow-conflicts will present conflicting
patches, because --skip-conflicts is completely suppressed. Given the
names of the options, it seems counterintuitive to me that this should
Arguably this is a failing of --don't-allow-conflicts, but we've already
discussed whether that should be repurposed to skip conflicts and the
conclusion seems to be "no" because of the loss of atomicity on
>> 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 create.
I'm only saying that if the user specifies --skip-conflicts as a
default, they'd have to explicitly use --no-skip-conflicts to turn it
off [at least, I think darcs has automatic negation of arguments using
--no-..., if not then it should :-)]
>> 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
> 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).
I am arguing that making these options mutually exclusive is not
necessarily intuitive (and hence clean, simple to use and remember),
because out of all of them, only --skip-conflicts has an impact on
interactive patch selection. Again, this isn't an issue about the code,
but about what the user sees.
I believe that in fact they are mostly orthogonal, except in that using
--skip-conflicts happens to have the side-effect of making
--don't-allow-conflicts and --mark-conflicts irrelevant.
Perhaps the real answer is that we should figure out the right UI for
all these options, including the --external-merge one you mention in
your other email, rather than trying to bolt --skip-conflicts on top of
Please access the attached hyperlink for an important electronic communications disclaimer:
More information about the darcs-users