[PATCH] match: adding non-recursive directory matching

[Rodrigo Damazio]

The issue is that glob:foo/* is recursive in some cases - e.g. "hg files -I
glob:contrib/*" in the hg repo gives me subdirectories of contrib
recursively (including e.g. contrib/docker/apache-server, two levels down).
After discussing a bit more offline with Martin: I'll check if that's a bug
in the matcher's visitdir (rather than a design limitation of glob) before
following up on this change.


On Tue, Oct 18, 2016 at 7:39 AM, Yuya Nishihara <yuya at tcha.org> wrote:

> On 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?
>
> Sounds good to me.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20161020/7883dd84/attachment.html>