[PATCH] match: adding non-recursive directory matching

[Rodrigo Damazio]

Sending updated patch via pushgate (description changed).


On Mon, Oct 24, 2016 at 10:34 AM, Rodrigo Damazio <rdamazio at google.com>
wrote:

> It sounds like we'd like to do 3 somewhat orthogonal things:
> - allow user to specify the directory the pattern is relative to
> (root/cwd/any)
> - allow the user to specify recursiveness/non-recursiveness consistently
> (not covered by the *path patterns, but could be the defined behavior for
> the globs)
> - clean up the matcher API (discussed during Sprint)
>
> Doing all 3 together would probably take some time and a lot of
> back-and-forth, so I'm wondering if it'd be ok to start by updating this
> patch to implement "rootglob" with consistent recursiveness behavior, and
> we can then more slowly add the other patterns and converge on a cleaner
> API?
>
> Also, for discussion: I assume the *path patterns will be recursive when
> they reference a directory. Do we also want a non-recursive equivalent
> (rootexact, rootfiles, rootnonrecursive or something like that)?
>
> Thanks
> Rodrigo
>
>
>
> On Mon, Oct 24, 2016 at 6:21 AM, Pierre-Yves David <
> pierre-yves.david at ens-lyon.org> wrote:
>
>>
>>
>> On 10/21/2016 05:13 PM, FUJIWARA Katsunori wrote:
>>
>>> At Tue, 18 Oct 2016 10:12:07 -0400,
>>> Augie Fackler wrote:
>>>
>>>>
>>>> On Tue, Oct 18, 2016 at 9:52 AM, Yuya Nishihara <yuya at tcha.org> wrote:
>>>>
>>>>> On Tue, 18 Oct 2016 09:40:36 -0400, Augie Fackler wrote:
>>>>>
>>>>>> On Oct 18, 2016, at 09:38, Yuya Nishihara <yuya at tcha.org> wrote:
>>>>>>>
>>>>>>>> After coordinating on irc to figure out what this proposal actually
>>>>>>>> is, I've noticed that the semantics of this "exact" proposal are
>>>>>>>> exactly what "glob" does today, which means (I think) that
>>>>>>>> "files:foo/bar" should be representable as "glob:foo/bar/*" - what
>>>>>>>> am
>>>>>>>> I missing?
>>>>>>>>
>>>>>>>
>>>>>>> Maybe we want a "glob" relative to the repo root?
>>>>>>>
>>>>>>
>>>>>> As far as I can tell, it already is. "relglob:" is relative to your
>>>>>> location in the repo according to the docs.
>>>>>>
>>>>>
>>>>> Unfortunately that isn't.
>>>>>
>>>>>         'glob:<glob>' - a glob relative to cwd
>>>>>         'relglob:<glob>' - an unrooted glob (*.c matches C files in
>>>>> all dirs)
>>>>>
>>>>> Don't ask me why. ;-)
>>>>>
>>>>
>>>> Oh wat. It looks like narrowhg might change this behavior in narrowed
>>>> repositories, thus my additional confusion.
>>>>
>>>> Maybe we should add "absglob" that is always repo-root-absolute. How
>>>> do we feel about that overall?
>>>>
>>>
>>> FYI, current pattern matching is implemented as below. This was
>>> chatted in "non-recursive directory matching" session of 4.0 sprint,
>>> and sorry for my late posting of this translation from
>>> http://d.hatena.ne.jp/flying-foozy/20140107/1389087728 in Japanese, as
>>> my backlog of the last sprint.
>>>
>>>   ============ ======= ======= ===========
>>>   pattern type root-ed cwd-ed  any-of-path
>>>   ============ ======= ======= ===========
>>>   wildcard     ---     glob    relglob
>>>   regexp       re      ---     relre
>>>   raw string   path    relpath ---
>>>   ============ ======= ======= ===========
>>>
>>>   If rule is read in from file (e.g. .hgignore):
>>>
>>>     * "glob" is treated as "relglob"
>>>     * "re" is treated as "relre"
>>>
>>>   This is mentioned in "hg help patterns" and "hg help hgignore", but
>>>   syntax name "relglob" and "relre" themselves aren't explained.
>>>
>>>   "end of name" matching is required:
>>>
>>>     * for glob/relglob as PATTERN (e.g. argument in command line), but
>>>     * not for glob/relglob as INCLUDES/EXCLUDES, or other pattern
>>> syntaxes
>>>
>>>   For example, file "foo/bar/baz" is:
>>>
>>>     * not matched at "hg files glob:foo/bar"
>>>     * but matched at "hg file -I glob:foo/bar"
>>>
>>>   This isn't mentioned in any help document :-<, and the latter seems
>>>   to cause the issue mentioned in this patch series.
>>>
>>> How about introducing new systematic names like below to re-organize
>>> current complicated mapping between names and matching ? (and enable
>>> "end of name" matching by "-eon" suffix or so)
>>>
>>>   ============ ======== ======= ===========
>>>   pattern type root-ed  cwd-ed  any-of-path
>>>   ============ ======== ======= ===========
>>>   wildcard     rootglob cwdglob anyglob
>>>   regexp       rootre   cwdre   anyre
>>>   raw string   rootpath cwdpath anypath
>>>   ============ ======== ======= ===========
>>>
>>
>> Moving toward a more regular and clear feature set and naming seems a
>> win. I'm +1 for moving in that direction.
>>
>> Cheers,
>>
>> --
>> Pierre-Yves David
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20161025/990d407d/attachment.html>