Accessing hidden commits by hash (directaccess extension)

Pulkit Goyal 7895pulkit at gmail.com
Thu Jan 25 12:35:21 UTC 2018


The functionality to access hidden commits will be present in upcoming
Mercurial release (4.5). The use it, you need to set
`experimental.directaccess=True`. This will enable accessing hidden
commits for commands listed below using hash. If you also want to
access them using rev numbers, set
`experimental.directaccess.revnums=True`.

List of the commands which support the functionality are:
  * export
  * log
  * cat
  * diff
  * files
  * identify
  * annotate
  * status
  * archive
  * heads
  * manifest
  * parents
  * update (with a warning)
  * revert
  * bookmarks (with a warning)

There is also an API `scmutil.unhidehashlikerevs()` which can be used
to add this functionality to other extensions.

On Thu, Aug 31, 2017 at 6:27 PM, Ryan McElroy <rm at fb.com> wrote:
> 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> 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=
>
>
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>


More information about the Mercurial-devel mailing list