[PATCH V2] help: hide command line options marked as "advanced"

Pierre-Yves David pierre-yves.david at ens-lyon.org
Fri Nov 25 03:47:27 EST 2016



On 11/19/2016 03:36 PM, Jun Wu wrote:
> Excerpts from Pierre-Yves David's message of 2016-11-19 11:05:25 +0100:
>>
>> On 11/02/2016 03:10 AM, Jun Wu wrote:
>>> Excerpts from Pierre-Yves David's message of 2016-11-02 02:52:36 +0100:
>>>>
>>>> On 11/02/2016 12:49 AM, Jun Wu wrote:
>>>>> Excerpts from Pierre-Yves David's message of 2016-11-02 00:41:03 +0100:
>>>>>>
>>>>>> On 11/01/2016 04:08 PM, Jun Wu wrote:
>>>>>>> # HG changeset patch
>>>>>>> # User Jun Wu <quark at fb.com>
>>>>>>> # Date 1478011845 0
>>>>>>> #      Tue Nov 01 14:50:45 2016 +0000
>>>>>>> # Node ID 058074cf24ce30ee0bc6d6a4d91fbe35631f8e8e
>>>>>>> # Parent  264f00b3e5f045ac5b58d79e2a3976585f4e7739
>>>>>>> # Available At https://bitbucket.org/quark-zju/hg-draft
>>>>>>> #              hg pull https://bitbucket.org/quark-zju/hg-draft    -r 058074cf24ce
>>>>>>> help: hide command line options marked as "advanced"
>>>>>>>
>>>>>>> Previously, we have keywords like "(DEPRECATED)" and "(EXPERIMENTAL)" to
>>>>>>> hide command line options in non-verbose help output.
>>>>>>>
>>>>>>> However, sometimes an option is neither deprecated nor experimental. It's
>>>>>>> well-tested and working, but just not designed to average users. This patch
>>>>>>> adds a keyword "(ADVANCED)" to fit in such use cases.
>>>>>>>
>>>>>>> Thanks rom1dep for the suggestion of the word "advanced".
>>>>>>
>>>>>> Do we have any candidate for this in core ?
>>>                     ^^^^^^^^^
>>>                     It can be "other keyword candidates".
>>>
>>>>>
>>>>> It should be better than "(VERBOSE)".
>>>>
>>>> I'm very confused by this reply. My question is
>>>>
>>>> "Do we currently have any flag in core that could benefit from this new
>>>> feature?"
>>>
>>> I couldn't find candidates easily. For evolve, I think "graft -o/-O" may
>>> qualify.
>>
>> I'm more looking for user in core.
>>
>> hg serve have some flag only used by other script, they seems good
>> candidate. This could make good initial user
>>
>>      --stdio                     for remote clients
>>      --cmdserver MODE            for remote clients
>>
>> The --ssh related flag for clone and push/pull are probably good
>> candidate too (but it is less clear)
>>
>> Can you send a V3 flag --stdio and --cmdserver as advanced, I would most
>> probably take that.
>
> Do you mean folding the flag changes into this patch? I think that should be
> a separate patch (and you agreed on this on IRC).
>
> I'm not sure what needs to be changed for this patch. If I send a V3 of two
> patches where the second is the flag change as you described, the first
> patch in V3 would be identical to the current one. I'm not sure why is that
> better than queuing this + sending just the flag change patch.

That patch seems fine but got dropped from patchwork a while back. It 
seem simpler for you to resend it alongside the other if you don't mind.

Cheers,

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list