Re: Accessing hidden commits by hash (directaccess extension)

[Pulkit Goyal]

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  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  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@mercurial-scm.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mercurial-2Dscm.org_mailman_listinfo_mercurial-2Ddevel=DwIGaQ=5VD0RTtNlTh3ycd41b3MUw=Jw8rundaE7TbmqBYd1txIQ=0W7u7KGbbI_6yxsgakY2iIDg1mdpE4b7aCCmLxK9gQk=a1LhMUxH4MprRZ0a3hJEFc4Bp2T21ZXdBXfO2vmIy1Q=
>
>
>
> ___
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: 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 > 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@mercurial-scm.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mercurial-2Dscm.org_mailman_listinfo_mercurial-2Ddevel=DwIGaQ=5VD0RTtNlTh3ycd41b3MUw=Jw8rundaE7TbmqBYd1txIQ=0W7u7KGbbI_6yxsgakY2iIDg1mdpE4b7aCCmLxK9gQk=a1LhMUxH4MprRZ0a3hJEFc4Bp2T21ZXdBXfO2vmIy1Q=


___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Accessing hidden commits by hash (directaccess extension)

[Ryan McElroy]

On 8/28/17 7:00 PM, Augie Fackler wrote:
On Aug 28, 2017, at 13:13, Durham Goode > 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@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Accessing hidden commits by hash (directaccess extension)

[Augie Fackler]

> On Aug 28, 2017, at 13:13, Durham Goode  wrote:
> 
> 
> 
> On 8/27/17 6:51 PM, Augie Fackler wrote:
>> On Fri, Aug 25, 2017 at 11:26:05AM -0700, Durham Goode wrote:
>> [...]
>>> Preventing Mistakes
>>> ===
>>> 
>>> One of the reasons for preventing users from accessing hidden commits is to
>>> prevent them from doing bad things with them (like pushing them, or amending
>>> them and causing divergence). To address this, directaccess treats read
>>> commands, recoverable-write commands, and unrecoverable-write commands
>>> separately.
>>> 
>>> For read commands (a whitelist of commands in the code), it allows the user
>>> to access the commit like normal.
>>> 
>>> For recoverable-write commands, like commit/amend/rebase, it prints
>>> "Warning: accessing hidden changesets %s for write operation".
>>> 
>>> For unrecoverable-write commands (a whitelist), like push and serve, it
>>> blocks the command like normal, with the 'abort: hidden revision' error.
>> 
>> 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? 

> 
> As for custom aliases, I believe directaccess hooks in at the command 
> function level, so it doesn't matter what you type at the command line, as 
> long as it invokes the command function.

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Accessing hidden commits by hash (directaccess extension)

[Durham Goode]

On 8/27/17 6:51 PM, Augie Fackler wrote:

On Fri, Aug 25, 2017 at 11:26:05AM -0700, Durham Goode wrote:
[...]

Preventing Mistakes
===

One of the reasons for preventing users from accessing hidden commits is to
prevent them from doing bad things with them (like pushing them, or amending
them and causing divergence). To address this, directaccess treats read
commands, recoverable-write commands, and unrecoverable-write commands
separately.

For read commands (a whitelist of commands in the code), it allows the user
to access the commit like normal.

For recoverable-write commands, like commit/amend/rebase, it prints
"Warning: accessing hidden changesets %s for write operation".

For unrecoverable-write commands (a whitelist), like push and serve, it
blocks the command like normal, with the 'abort: hidden revision' error.


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.


As for custom aliases, I believe directaccess hooks in at the command 
function level, so it doesn't matter what you type at the command line, 
as long as it invokes the command function.

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Accessing hidden commits by hash (directaccess extension)

[Augie Fackler]

On Fri, Aug 25, 2017 at 11:26:05AM -0700, Durham Goode wrote:
[...]
> Preventing Mistakes
> ===
>
> One of the reasons for preventing users from accessing hidden commits is to
> prevent them from doing bad things with them (like pushing them, or amending
> them and causing divergence). To address this, directaccess treats read
> commands, recoverable-write commands, and unrecoverable-write commands
> separately.
>
> For read commands (a whitelist of commands in the code), it allows the user
> to access the commit like normal.
>
> For recoverable-write commands, like commit/amend/rebase, it prints
> "Warning: accessing hidden changesets %s for write operation".
>
> For unrecoverable-write commands (a whitelist), like push and serve, it
> blocks the command like normal, with the 'abort: hidden revision' error.

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?
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Accessing hidden commits by hash (directaccess extension)

[Danek Duvall]

This is great.  I've been hitting my head against this ever since I started
using evolve, and I'll be thrilled to have this functionality.

A couple of questions:

  - If a revision range is given that ends (or begins, I suppose) with a
hidden changeset, will any intervening hidden changesets also be
temporarily unhidden?

  - The recoverable-write commands often pop you into an editor before any
warning can be seen and understood.  Should the warning be available in
the editor template?

  - The unrecoverable-write commands could probably stand to explain why
they're preventing the operation from happening, but perhaps more
importantly, if you use --hidden with them, will they actually
push/serve/whatever?  I guess I can see wanting a complete clone of a
repo, including hidden changesets, so pushing them around would make
sense in that context, but I thought we weren't going there.

Along similar lines, I've also wanted the ability to push and pull secret
changesets between (non-publishing) repositories, but only when specificied
by name like this.  Seems like there could be some shared mechanism there,
if it's not just me.

Danek
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel