[PATCH] match: adding non-recursive directory matching

[Pierre-Yves David]

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