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

Augie Fackler raf at durin42.com
Mon Oct 31 21:47:35 EDT 2016


> 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.)

> 
>> 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.

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.

> Cheers,
> 
> --
> Pierre-Yves David
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20161031/f2e6ca87/attachment.sig>


More information about the Mercurial-devel mailing list