[PATCH] show: new extension for displaying various repository data

Durham Goode durham at fb.com
Fri Mar 24 13:18:42 EDT 2017



On 3/22/17 8:29 AM, Gregory Szorc wrote:
>
>
>> On Mar 22, 2017, at 04:51, Ryan McElroy <rm at fb.com> wrote:
>>
>>
>>
>>> On 3/22/17 7:29 AM, Sean Farley wrote:
>>> Yuya Nishihara <yuya at tcha.org> writes:
>>>
>>>>> On Sun, 12 Mar 2017 21:38:00 -0700, Gregory Szorc wrote:
>>>>> # HG changeset patch
>>>>> # User Gregory Szorc <gregory.szorc at gmail.com>
>>>>> # Date 1489378362 25200
>>>>> #      Sun Mar 12 21:12:42 2017 -0700
>>>>> # Node ID d30057d358076cbe7d632cd573095af97543f932
>>>>> # Parent  1c3352d7eaf24533ad52d4b8a024211e9189fb0b
>>>>> show: new extension for displaying various repository data
>>>> The idea sounds nice to me. I just checked minor implementation details
>>>> about formatter.
>>> Just a quick reply (as I whittle down my backlog), but a lot of people
>>> (including myself) have a 'show' alias (inspired by 'git show').
>>>
>>> That may or may not be a factor in this.
>>
>> Greg called this out specifically in his excellent summary.
>>
>> FB also has a "show" extension that replaced our "show" alias: https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.org_facebook_hg-2Dexperimental_src_default_hgext3rd_show.py&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=nuarHzhP1wi1T9iURRCj1A&m=KZNXs3QMg2M7YtCvXYwgouTxwTN2WFhsYLOLHtLfE2Y&s=qWD0RFF73TrSukNubnCJl-EdsGcgjpl5olyQNX88XQ4&e=
>
> At Paris, people from Facebook mildly objected to "show" because of the conflict.
>
> At Mountain View, Durham said to just use "show" and FB would deal with it.
>
> I myself was convinced to use "display" after Paris and that's what I initially implemented. Justification for "display" was summarized in that RFC patch's commit message. However, enough people said the reasons weren't strong enough and Durham gave me a green light, so I changed to my preference: show.
>
> Anyway, the command and extension name is a bikeshed and can be changed before 4.2. I'd prefer review focus on the behavior so we can get something landed and iterate on the feature. I *really* want a smartlog/wip feature in the core distribution and this extension/command is where it will live.

I'd just pick what makes the most sense for Mercurial users, and not 
worry about what people have aliased, etc.  The conflict with 'git show' 
is a valid concern though.

For 'hg view', you could argue that hgk is just one implementation of 
this new 'view' paradigm, and maybe it could change it's command line to 
accept the same bookmark/smartlog/etc inputs as the proposed 'hg 
view/show'.  That might let us justify using 'hg view'


More information about the Mercurial-devel mailing list