Eric Kow wrote:
> On Mon, Oct 05, 2009 at 14:28:29 +0100, Sittampalam, Ganesh wrote:
>> 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
>> interactive selection.
>
> It sounds like we have really three cascading choices here:
>
> --offer-conflicts
> --dont-offer-conflicts
>
> --allow-conflicts
> --dont-allow-conflicts
>
> --mark-conflicts
> --dont-mark-conflicts
>
> With the each later one in the sequence being effectively meaningless
> if you select 'dont' for the one before it.
I suggest that /any/ tuple of mutually exclusive options be bundled into one
option with an argument:
--offer-conflicts=[yes|no]
--allow-conflicts=[yes|no]
--mark-conflicts=[yes|no]
(Please read on before answering, this is not my final proposal.)
This makes the that fact that they are mutually exclusive much more obvious
to the user. It also reduces the number of option names the user has to
remember and removes the confusion resulting from different ways to express
negation (as in --dont-compress vs. --no-summary).
In this particular case I'd argue for an enumeration of all sensible
combinations, especially since they are nested:
--handle-conflicts=[none|offer|allow|mark]
with
none:
no conflicts allowed, don't even offer conflicting patches
offer:
offer (list) conflicting patches but do not allow them to be applied
allow:
allow conflicts, don't mark them
mark:
allow conflicts, mark them (default)
(Please regard the names of the option values as provisional, they an surely
be improved.)
One point to consider w.r.t. 'offer': This would be a lot more useful if the
user is forewarned that she will not be able to apply the patch (taking
patches the user has already selected into consideration, if necessary).
Cheers
Ben
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
