[PATCH 4 of 4] mq: introduce mq.check setting

[Patrick Mézard]

Le 12/05/12 16:13, Patrick Mézard a écrit :
> Le 12/05/12 15:00, Angel Ezquerra a écrit :
>> On Sat, May 12, 2012 at 11:00 AM, Patrick Mézard <patrick at mezard.eu> wrote:
>>> Le 12/05/12 10:37, Angel Ezquerra a écrit :
>>>> On May 12, 2012 10:09 AM, "Matt Mackall" <mpm at selenic.com> wrote:
>>>>>
>>>>> On Sat, 2012-05-12 at 01:12 +0200, Patrick Mezard wrote:
>>>>>> # HG changeset patch
>>>>>> # User Patrick Mezard <patrick at mezard.eu>
>>>>>> # Date 1336774770 -7200
>>>>>> # Node ID ed81cb27341e285d539617ba961f48c69dd18135
>>>>>> # Parent  f4da2aeb000408aa54f59829acb092ec85914475
>>>>>> mq: introduce mq.check setting
>>>>>
>>>>> Nice, these are queued for default.
>>>>
>>>> Patrick,
>>>>
>>>> I'm curious, why did you choose "check" as the name for this option? It
>>>> does not seem obvious to me...
>>>
>>> I have not given much thought to it. --check makes it sound like qpush/qpop will closely "check" the local changes before deciding to bail out or not. The setting is named after the command line option. Maybe this is a mistake, if you have something better to suggest, feel free to submit a patch, that is exactly the right time to change it.
>>
>> There is a --check (-c) option for update. Its definition is"
>>
>> -c --check     update across branches if no uncommitted changes
>>
>> It does not sound anything like this option (IMHO). In fact, it seems
>> as if where quite the oposite. On the hg help update text it says:
>>
>> "    2. With the -c/--check option, the update is aborted and the uncommitted
>>        changes are preserved."
>>
>> That is, with the -c option, the update will be aborted if there are
>> uncommitted changes, which is in fact the opposite of what this does,
>> isn't it?
> 
> You may be right.
>  
>> what about --nocheck (-n)? After all this does the opposite thing of
>> what --check does for update (if I undestand things correctly).
> 
> [-n] is used for --dry-run so not this short option. Obviously, it is difficult for me to consider --no-check, since the code actually checks more things than the regular version (but is more lenient in its findings). Also, --no-check feels a bit like "I am not checking anything, all bets are off, I hope you had backups". But maybe.
> 
> What other people think?

Idan: --disjoint
Me: --keep-changes or --keep

--
Patrick Mézard