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

Angel Ezquerra angel.ezquerra at gmail.com
Sat May 12 08:00:17 CDT 2012


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?

what about --nocheck (-n)? After all this does the opposite thing of
what --check does for update (if I undestand things correctly).

If you guys agree with this I can probably send a patch sometime next week.

>> Also I'm a bit surprised that the backward compatibility rule applies here,
>> given that this simply lets you do things that before would simply fail. As
>> you said in your commit message this is probably the behavior expected by
>> most users.
>
> See http://selenic.com/hg/rev/e9ed3506f066 for the qpush attempt.

Thanks for the pointer. It makes more sense now.

>> I didn't look too carefully at your patch, so maybe you already did that,
>> but wouldn't it make sense to mention this new option on the error message
>> that is shown if you don't use this option?
>
> Certainly, anything to make it (more) discoverable would be great. The setting should be mentioned in qpush/qpop/qgoto help as well.
>

Nice.

Cheers,

Angel


More information about the Mercurial-devel mailing list