This should probably be considered an RFC patch, especially given how late in the cycle it is. I'm not opposed to punting this to the next cycle.

The main feature and implementation looks good to me. My questions are about :minversion and localrepository.anyrevs.

Instead of implementing it at revset.matchany, have you considered localrepository.anyrevs? That might be easier to maintain the current behavior, ex. D97 might become unnecessary.

Big +1 on this functionality, and I'd be happy to experiment with it now. I couldn't quite figure it out from an extension. Also +1 on doing this for filesets.

My use case is less about generic revsets (e.g., nudge = push -r .), and more about defining ones that collect the paths for various products in the repo. It makes sense to lock those into each revision as the codebase evolves. So my initial thoughts for next cycle are:

1. Hopefully the paths can define filesets in .hgfileset, and then the fileset be used to define the revset (probably as input to 'files()'), to avoid duplication. (It's not clear to me if there will be ordering/dependency issues when these are read in.)

2. I think using wdir() by default makes sense. But an option to use another rev makes sense in some cases (consider hg archive -r 1234 -I 'set:product1()', without updating to 1234).

3. I can see cases where the repo defined alias should be enforced (e.g. a release script running hg archive). I think HGRCPATH= ignores every hgrc except .hg/hgrc, right? A config option that the script knows about to alter the default behavior seems useful.

Not directly related to this, but I've also been wondering how to get defined revsetaliases more discoverable. Maybe recognizing minirst help text inside the # comments in the section, and inserting them into the core help? I don't think an end user cares about the difference between a revset proper and a revsetalias.

Can we have a single source file for project's revset/fileset aliases and maybe templates?
I don't think it's good idea to create .hgxxx file per config section.

[revsetalias]
filealiasall = all()

[filesetalias]
...

Perhaps they could be opt-in by user config, e.g. experimental.revsetaliasfromrepo=*.

In D98#2104, @yuja wrote:

Can we have a single source file for project's revset/fileset aliases and maybe templates?
I don't think it's good idea to create .hgxxx file per config section.

[revsetalias]
filealiasall = all()
[filesetalias]
...

Perhaps they could be opt-in by user config, e.g. experimental.revsetaliasfromrepo=*.

I like it. What else should we allow in here? Are there security concerns we should think through?

What else should we allow in here? Are there security concerns we should think through?

Probably safe, but could be used for DoS attack:

• filesetalias (not implemented)
• revsetalias
• committemplate
• templatealias
• templates

Unsafe (should never be allowed):

• alias (arbitrary command execution by shell alias or option like bisect -c CMD)

Obviously, they are all unsafe depending on extension predicates/functions/keywords, such
as a revset shelling out arbitrary inputs.

Security-wise, the "shelling out revset" seems hard to solve cleanly. By having %include ../hgrc in $REPO/.hg/hgrc, we could already read config in working copy for a trusted repo.

It seems to me that a lot of security work (ex. knowing the "origin" when executing a revset, marking config items or sections as safe or unsafe by extensions) are required to be able to turn on this feature by default. If we don't turn this on by default because of security, the %include ../hgrc approach seems practical enough already.

Security-wise, the "shelling out revset" seems hard to solve cleanly.

Yes, and IMHO the only reasonable solution is to not add such revset functions.
revsets and filesets can be executed through the web UI.

In D98#4834, @quark wrote:

It seems to me that a lot of security work (ex. knowing the "origin" when executing a revset, marking config items or sections as safe or unsafe by extensions) are required to be able to turn on this feature by default. If we don't turn this on by default because of security, the %include ../hgrc approach seems practical enough already.

I thought about doing this, instead of fixing up a stripped down projrc extension. But then you have to get every developer to edit the local .hg/hgrc file for every clone they have. So even if we have to have this off by default, I still see value in this in a corporate environment.

I couldn't tell from Yuya's comment if "... not add such revset functions" means don't add support for external revsets at all, or filter them out of this file by default, or something else.

I couldn't tell from Yuya's comment if "... not add such revset functions" means

I meant "don't load unsafe extensions." revsets and filesets have to be secure against
malicious input because they are accessible through the Web UI. It's up to users to
make a security hole by loading unsafe extensions.

In D98#6041, @mharbison72 wrote:

I thought about doing this, instead of fixing up a stripped down projrc extension. But then you have to get every developer to edit the local .hg/hgrc file for every clone they have. So even if we have to have this off by default, I still see value in this in a corporate environment.

Our solution for this is to tell people to use a special clone script.

There are a number of security and user control issues at play here.

For security, we need to take a long hard look at what configs can be modified by in-repo files. Revsets already have a "safe" flag that controls what to expose on hgweb. We likely need more of this.

For user control, I could imagine something hooked into hg clone and hg pull. If we encounter a well-known in-tree config file, we can prompt or notify the user to enable it. Enabling would be as simple as dropping a %include into .hg/hgrc or something. We could expose global config options to control the default behavior. e.g. always install, prompt, etc.

This would be a good discussion to have at the Sprint!