Accessing hidden commits by hash (directaccess extension)

[Ryan McElroy]

I also synced up in person with Pulkit yesterday about the directaccess 
extension. I wanted to record the key outcomes of our conversation here 
to ensure the conversation record is kept in one place.


Q: Pulkit asked me if using revision numbers should also unhide changesets.

A: I said no, at FB we went to lengths to ensure that this was not the 
case. In large repos, someone referring to a changeset by its revision 
number is a mistake or a mistake waiting to happen. Revision numbers are 
generally not shorter than a the shortest hash, and sometimes 
accidentally copy-pasting a truncated revision number will lead to much 
worse consequences than a truncated hash, which at least will abort 
saying the hash is an ambiguous prefix. Therefore, we do not want to 
unhide changesets by revision number.


Q: Pulkit asked about the to get the list of commands that should be 
white/grey/black-listed for accessing hidden changesets.

A: I really like Augie's idea of having this information be encoded in 
the @command decorator. This will ensure future compatibility without 
continuously updating lists of commands.


Q: Pulkit asked if a good place to implement this would be in the hidden 
changeset abort code in core.

A: I don't have a strong opinion here. I do like config options over 
additional extensions where possible, so I like ti for that reason, but 
I don't know if it's the best way to go about it.

Cheers,

~Ryan


On 8/31/17 1:39 PM, Ryan McElroy wrote:
> On 8/28/17 7:00 PM, Augie Fackler wrote:
>> On Aug 28, 2017, at 13:13, Durham Goode <durham at fb.com 
>> <mailto:durham at fb.com>> wrote:
>>>
>>> On 8/27/17 6:51 PM, Augie Fackler wrote:
>>>>
>>>> It sounds like you whitelist read and unrecoverable-write
>>>> commands. Does that mean "ercoverable-write" commands are inferred
>>>> from not being in those two whitelists? How has that interacted with
>>>> users finding random extensions or defining custom aliases?
>>>
>>> Yea, the default behavior is warn-the-user.  Very, very few of our 
>>> users have ever enabled random extensions so that has not been an issue.
>>
>> Hm, okay. Then one thing we should probably do is hoist these lists 
>> into core, and make it so they're trivial to amend so that 
>> out-of-tree extensions can correctly categorize their behavior. I'd 
>> imagine this could have other value, so maybe it should be in the 
>> @command decorator?
>>
>
> I like the idea of adding this to the command decorator. I think that 
> will prevent new commands from being put into the wrong category.
>
>
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mercurial-2Dscm.org_mailman_listinfo_mercurial-2Ddevel&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=Jw8rundaE7TbmqBYd1txIQ&m=0W7u7KGbbI_6yxsgakY2iIDg1mdpE4b7aCCmLxK9gQk&s=a1LhMUxH4MprRZ0a3hJEFc4Bp2T21ZXdBXfO2vmIy1Q&e=

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170831/fe028f8a/attachment.html>