[PATCH] match: adding support for repository-root-based globs

[Pierre-Yves David]

On 11/01/2016 01:50 PM, Yuya Nishihara wrote:
> On Mon, 31 Oct 2016 21:47:35 -0400, Augie Fackler wrote:
>>> On Oct 28, 2016, at 4:40 AM, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
>>> On 10/25/2016 09:41 AM, Rodrigo Damazio Bovendorp via Mercurial-devel wrote:
>>>> # HG changeset patch
>>>> # User Rodrigo Damazio Bovendorp <rdamazio at google.com>
>>>> # Date 1475944120 25200
>>>> #      Sat Oct 08 09:28:40 2016 -0700
>>>> # Node ID e8454de81600e092f05aa22ecbac32925b70d074
>>>> # Parent  260af19891f2bed679a662be07d1379bb8207592
>>>> match: adding support for repository-root-based globs
>>>>
>>>> The broader plan is to add explicit base directories for all patterns:
>>>> ============ ======== ======= ===========
>>>> pattern type root-ed  cwd-ed  any-of-path
>>>> ============ ======== ======= ===========
>>>> wildcard     rootglob cwdglob anyglob
>>>> regexp       rootre   cwdre   anyre
>>>> raw string   rootpath cwdpath anypath
>>>> ============ ======== ======= ===========
>>>> (table by foozy)
>>>
>>> The subject seems complicated enough that creating a Plan page seems relevant. This would help other people to follow what the problem space.
>>>
>>> https://www.mercurial-scm.org/wiki/WriteANewFeaturePlan
>>
>> I’m not sure if it needs a plan page. It strikes me as believable (perhaps even likely?) that rootglob will be the only part of this implemented for a long time, perhaps ever. (Having the whole table makes good sense to me though, because now we’ve though through the future in case it ever comes.)

If I'm counting correctly, this is at least the third time matcher 
specification is touched in the history of the project. This instance 
have already created multiple email threads with interesting data 
"hidden" into them.

I think a plan page is important to give clear picture of the situation 
and the proposed solution in a single place. This would help increased 
the number of eyes on this topic that history have proved complex.

Especially give how often this topic came up I think it important to 
make sure we actually map the problem space and nail the issue once and 
for all. I'm a bit concerned we could be taking the minimal step to 
snipe a specific requirement here without actually moving toward a real 
closure providing a simplified solution that fit all all users.

Regarding how far we'll go in that plan, I hope that at least 
"rootre:/rootpath:" will be implement for feature parity with glob.

>>>> I'm starting by adding rootglob.
>>>> One important characteristic and difference from the older glob types is
>>>> that * will never match recursively, even when the glob is used as an include
>>>> pattern.
>>>
>>> This seems a bit strange to me. Given that the current glob matcher is already not recursive, why don't we work on an alternative non recursive -I flag instead?
>>
>> That means we’ll have a new flag that alters the behavior of existing matchers in subtle ways. It also requires cooperation from every command that we want to add new globbing features to, including extensions, whereas if we can add a couple of new atoms (as outlined in the proposal from foozy) we get consistent behavior across all matchers.

Command using -I/-X option usually just add the 'walkopts' list to their 
option and then pass their 'opts' dict to 'scmutil.match(…)'. So 
improving the command flag situation in a unified way does not seems too 
scary.

My main concern here is that the vast majority of user will still use 
the basic glob we expose without any prefix. If the most common matcher 
behave "differently" than all the others, that will get confusing.
That said, the exact state of all existing matchers behavior is getting 
fuzzier in my head as the discussion progress. This is one of the reason 
I would like to see the current situation and the Foozy plan summarized 
into a plan page.

A good way to test¹ design is "how embarrassing is it to explain to new 
user" (that is correlated to the simplicity of the design). The recent 
discussion and confusion around matcher show that we are not great for 
the moment.

>> It’s a mistake that existing matchers have a recursive * behavior with --include, but it’s too late to change that. As such, I’d much rather have this proposal as currently stated.

> Given the current globsuffix thing is just for backward compatibility, new
> rootglob prefix makes sense to me. Fileset, which is relatively new, behaves
> in that way.

On one hand, this extra bits from Yuya increase my wish for a nice 
summary of the current situation + objective. On the other hand there it 
start to have enough core people who seems to know what they are doing 
on this topic to let them work together on this.

So I wish there was a plan page but if none of Foozy, Yuya or Augie 
think it is necessary, just go ahead.

> % hg files -I 'set:contrib/docker/*'
> contrib/docker/centos5
> contrib/docker/centos6
> contrib/docker/centos7
> contrib/docker/debian-jessie
> contrib/docker/fedora20
> contrib/docker/fedora21
> contrib/docker/ubuntu.template
>
> % hg files -I 'contrib/docker/*'
> contrib/docker/apache-server/Dockerfile
> contrib/docker/apache-server/README.rst
> contrib/docker/apache-server/entrypoint.sh
> contrib/docker/apache-server/hgwebconfig
> contrib/docker/apache-server/vhost.conf
> contrib/docker/centos5
> contrib/docker/centos6
> contrib/docker/centos7
> contrib/docker/debian-jessie
> contrib/docker/fedora20
> contrib/docker/fedora21
> contrib/docker/ubuntu.template

Cheers,

-- 
Pierre-Yves David

[1] I got it from Durham.