Accessing hidden commits by hash (directaccess extension)
Ryan McElroy
rm at fb.com
Thu Aug 31 12:57:21 UTC 2017
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://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170831/fe028f8a/attachment-0002.html>
More information about the Mercurial-devel
mailing list