[darcs-users] darcs patch: Resolveissue1588: make--dont-allow-conflicts filter ...

[Sittampalam, Ganesh]

Ben Franksen wrote:
> 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).   

One extra point to throw into the mix which I should have made clearer
earlier: the skip/offer behaviour also affects what the --all option
does, i.e. when interactive patch selection is bypassed/treated as
saying 'y' to everything. I think that perhaps makes the use of the word
"offer" inappropriate, unless we somehow split the scenario where --all
is used from the one where interactive selection actually happens.

Ganesh

=============================================================================== 
 Please access the attached hyperlink for an important electronic communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 ===============================================================================