<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 26, 2016 at 2:03 PM Rodrigo Damazio via Mercurial-devel <<a href="mailto:mercurial-devel@mercurial-scm.org" target="_blank">mercurial-devel@mercurial-<wbr>scm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail-m_5287844083015251867gmail_msg"><div class="gmail_extra gmail-m_5287844083015251867gmail_msg"><div class="gmail_quote gmail-m_5287844083015251867gmail_msg">On Wed, Oct 26, 2016 at 12:17 AM, FUJIWARA Katsunori <span dir="ltr" class="gmail-m_5287844083015251867gmail_msg"><<a href="mailto:foozy@lares.dti.ne.jp" class="gmail-m_5287844083015251867m_-8819813958087893088cremed gmail-m_5287844083015251867gmail_msg" target="_blank">foozy@lares.dti.ne.jp</a>></span> wrote:<br class="gmail-m_5287844083015251867gmail_msg"><blockquote class="gmail_quote gmail-m_5287844083015251867gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br class="gmail-m_5287844083015251867gmail_msg">
At Tue, 25 Oct 2016 19:51:59 -0700,<br class="gmail-m_5287844083015251867gmail_msg">
<div class="gmail-m_5287844083015251867gmail_msg"><div class="gmail-m_5287844083015251867m_-8819813958087893088h5 gmail-m_5287844083015251867gmail_msg">Rodrigo Damazio wrote:<br class="gmail-m_5287844083015251867gmail_msg">
><br class="gmail-m_5287844083015251867gmail_msg">
> On Tue, Oct 25, 2016 at 4:31 PM, FUJIWARA Katsunori <<a href="mailto:foozy@lares.dti.ne.jp" class="gmail-m_5287844083015251867m_-8819813958087893088cremed gmail-m_5287844083015251867gmail_msg" target="_blank">foozy@lares.dti.ne.jp</a>><br class="gmail-m_5287844083015251867gmail_msg">
> wrote:<br class="gmail-m_5287844083015251867gmail_msg">
><br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> > At Mon, 24 Oct 2016 10:34:52 -0700,<br class="gmail-m_5287844083015251867gmail_msg">
> > Rodrigo Damazio wrote:<br class="gmail-m_5287844083015251867gmail_msg">
> > ><br class="gmail-m_5287844083015251867gmail_msg">
> > > [1  <text/plain; UTF-8 (7bit)>]<br class="gmail-m_5287844083015251867gmail_msg">
> > > It sounds like we'd like to do 3 somewhat orthogonal things:<br class="gmail-m_5287844083015251867gmail_msg">
> > > - allow user to specify the directory the pattern is relative to<br class="gmail-m_5287844083015251867gmail_msg">
> > > (root/cwd/any)<br class="gmail-m_5287844083015251867gmail_msg">
> > > - allow the user to specify recursiveness/non-<wbr>recursiveness consistently<br class="gmail-m_5287844083015251867gmail_msg">
> > > (not covered by the *path patterns, but could be the defined behavior for<br class="gmail-m_5287844083015251867gmail_msg">
> > > the globs)<br class="gmail-m_5287844083015251867gmail_msg">
> > > - clean up the matcher API (discussed during Sprint)<br class="gmail-m_5287844083015251867gmail_msg">
> > ><br class="gmail-m_5287844083015251867gmail_msg">
> > > Doing all 3 together would probably take some time and a lot of<br class="gmail-m_5287844083015251867gmail_msg">
> > > back-and-forth, so I'm wondering if it'd be ok to start by updating this<br class="gmail-m_5287844083015251867gmail_msg">
> > > patch to implement "rootglob" with consistent recursiveness behavior, and<br class="gmail-m_5287844083015251867gmail_msg">
> > > we can then more slowly add the other patterns and converge on a cleaner<br class="gmail-m_5287844083015251867gmail_msg">
> > > API?<br class="gmail-m_5287844083015251867gmail_msg"></div></div></blockquote></div></div></div></blockquote><div><br></div><div>I'm obviously biased by working on the same project as you, but starting with rootglob makes sense to me. The matcher API cleanup, whatever that is, will probably be insignificantly harder because of rootglob. Even if we add all nine (or more?) suggested patterns suggested by Foozy, I don't think it will matter much for the refactoring.</div><div><br></div><div>However, I think the rootglob pattern has more impact to our users than it does to our codebase, so what we may want to do now is to document it better. I haven't thought much about it, but your patch didn't seem to include any documentation. I'm thinking that one of the tables in this thread should be in `hg help patterns` (i.e. mercurial/help/patterns.txt) and we can perhaps think about how we want that text to look once we add the other patterns Foozy suggested.</div><div><br></div><div>What do others think?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail-m_5287844083015251867gmail_msg"><div class="gmail_extra gmail-m_5287844083015251867gmail_msg"><div class="gmail_quote gmail-m_5287844083015251867gmail_msg"><blockquote class="gmail_quote gmail-m_5287844083015251867gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-m_5287844083015251867gmail_msg"><div class="gmail-m_5287844083015251867m_-8819813958087893088h5 gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> > (let's suspend posting revised series while code freeze period, to<br class="gmail-m_5287844083015251867gmail_msg">
> > focus on stabilization :-))<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
><br class="gmail-m_5287844083015251867gmail_msg">
> Sure, I understand you're under the freeze. Feel free to prioritize<br class="gmail-m_5287844083015251867gmail_msg">
> reviewing my patches appropriately.<br class="gmail-m_5287844083015251867gmail_msg">
> (notice the new patch is based on default, not stable)<br class="gmail-m_5287844083015251867gmail_msg">
><br class="gmail-m_5287844083015251867gmail_msg">
>     <a href="https://www.mercurial-scm.org/wiki/TimeBasedReleasePlan#Code_Freeze" rel="noreferrer" class="gmail-m_5287844083015251867m_-8819813958087893088cremed gmail-m_5287844083015251867gmail_msg" target="_blank">https://www.mercurial-scm.<wbr>org/wiki/TimeBasedReleasePlan#<wbr>Code_Freeze</a><br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> > In my previous reply, I assume that newly introduced syntaxes do:<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> >   - match recursively by default regardless of the way of passing<br class="gmail-m_5287844083015251867gmail_msg">
> >     (command line, -I/-X, ....), because of similarity with almost all<br class="gmail-m_5287844083015251867gmail_msg">
> >     of existing syntaxes<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> >     Only glob/relglob as PATTERN in command line require "end of name"<br class="gmail-m_5287844083015251867gmail_msg">
> >     matching.<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> >   - require additional "-eon" ("end of name") suffix for non-recursive<br class="gmail-m_5287844083015251867gmail_msg">
> >     matching (e.g. "rootglob-eon", "cwdre-eon", "anypath-eon", ...)<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> > But according to your revised patch, "rootglob" syntax matches<br class="gmail-m_5287844083015251867gmail_msg">
> > non-recursively. Would you assume as below ?<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> >   - newly introduced syntaxes match non-recursively by default<br class="gmail-m_5287844083015251867gmail_msg">
> >   - recursive matching requires any additional suffix (e.g. "-recursive")<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
><br class="gmail-m_5287844083015251867gmail_msg">
> Ah, the assumption is slightly different - the assumption is that for glob<br class="gmail-m_5287844083015251867gmail_msg">
> types, specifically, we're doing a full match, so that to get recursiveness<br class="gmail-m_5287844083015251867gmail_msg">
> at the end the user should specify /** or similar. This allows the user to<br class="gmail-m_5287844083015251867gmail_msg">
> do recursive or non-recursive matching by using * or ** as appropriate.<br class="gmail-m_5287844083015251867gmail_msg">
> I'll suggest that regex types also do a full match, and the user can end<br class="gmail-m_5287844083015251867gmail_msg">
> them with .* if they want it to be a prefix.<br class="gmail-m_5287844083015251867gmail_msg">
> I believe this is simpler and more flexible than having 18 different<br class="gmail-m_5287844083015251867gmail_msg">
> pattern types just to account for the different behavior of the matching. I<br class="gmail-m_5287844083015251867gmail_msg">
> considered that we could, likewise, make partial matching be the default,<br class="gmail-m_5287844083015251867gmail_msg">
> but I decided against that when making the patch because then it'd be<br class="gmail-m_5287844083015251867gmail_msg">
> impossible to make them non-recursive by a modifier, without doubling the<br class="gmail-m_5287844083015251867gmail_msg">
> number of matchers as you suggested.<br class="gmail-m_5287844083015251867gmail_msg">
<br class="gmail-m_5287844083015251867gmail_msg">
</div></div>It is right that glob and re pattern can switch<br class="gmail-m_5287844083015251867gmail_msg">
recursive/non-recursive by its own pattern, and controlling<br class="gmail-m_5287844083015251867gmail_msg">
recursive-ness by extra suffix of syntax name is redundant for them.<br class="gmail-m_5287844083015251867gmail_msg">
<br class="gmail-m_5287844083015251867gmail_msg">
I also forgot that adding "(?:$)" or "(?:$|/)" to "re:" pattern<br class="gmail-m_5287844083015251867gmail_msg">
correctly according to recursive-ness might cause trouble for<br class="gmail-m_5287844083015251867gmail_msg">
complicated regexp :-<</blockquote><blockquote class="gmail_quote gmail-m_5287844083015251867gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-m_5287844083015251867gmail_msg"><br class="gmail-m_5287844083015251867gmail_msg">
<br class="gmail-m_5287844083015251867gmail_msg">
> On the other hand, you assume that newly introduced *path syntaxes<br class="gmail-m_5287844083015251867gmail_msg">
> > will be recursive, as below. Would you assume that default<br class="gmail-m_5287844083015251867gmail_msg">
> > recursive-ness is different between *glob and *path syntaxes ?<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
><br class="gmail-m_5287844083015251867gmail_msg">
> path would be recursive, as will glob that ends with ** or regex that ends<br class="gmail-m_5287844083015251867gmail_msg">
> with .*<br class="gmail-m_5287844083015251867gmail_msg">
><br class="gmail-m_5287844083015251867gmail_msg">
><br class="gmail-m_5287844083015251867gmail_msg">
> > > Also, for discussion: I assume the *path patterns will be recursive when<br class="gmail-m_5287844083015251867gmail_msg">
> > > they reference a directory. Do we also want a non-recursive equivalent<br class="gmail-m_5287844083015251867gmail_msg">
> > > (rootexact, rootfiles, rootnonrecursive or something like that)?<br class="gmail-m_5287844083015251867gmail_msg">
<br class="gmail-m_5287844083015251867gmail_msg">
</span>How about adding syntax type "file"/"dir" ?<br class="gmail-m_5287844083015251867gmail_msg">
<br class="gmail-m_5287844083015251867gmail_msg">
  ===== ============= =================<br class="gmail-m_5287844083015251867gmail_msg">
  type  for recursive for non-recursive<br class="gmail-m_5287844083015251867gmail_msg">
  ===== ============= =================<br class="gmail-m_5287844083015251867gmail_msg">
  glob  use "**"      use "*"<br class="gmail-m_5287844083015251867gmail_msg">
  re    omit "$"      append "$"<br class="gmail-m_5287844083015251867gmail_msg">
  path  always(*1)    ----<br class="gmail-m_5287844083015251867gmail_msg">
  file  ----          always<br class="gmail-m_5287844083015251867gmail_msg">
  dir   always(*2)    ----<br class="gmail-m_5287844083015251867gmail_msg">
  ===== ============= =================<br class="gmail-m_5287844083015251867gmail_msg">
<br class="gmail-m_5287844083015251867gmail_msg">
  (*1) match against both file and directory<br class="gmail-m_5287844083015251867gmail_msg">
  (*2) match against only directory<br class="gmail-m_5287844083015251867gmail_msg">
<br class="gmail-m_5287844083015251867gmail_msg">
"dir" might be overkill, though :-) (is it useful in resolving name<br class="gmail-m_5287844083015251867gmail_msg">
collision at merging or so ?)<br class="gmail-m_5287844083015251867gmail_msg"></blockquote><div class="gmail-m_5287844083015251867gmail_msg"><br class="gmail-m_5287844083015251867gmail_msg"></div></div></div></div><div dir="ltr" class="gmail-m_5287844083015251867gmail_msg"><div class="gmail_extra gmail-m_5287844083015251867gmail_msg"><div class="gmail_quote gmail-m_5287844083015251867gmail_msg"><div class="gmail-m_5287844083015251867gmail_msg">foozy, thanks so much for the review and discussion.</div><div class="gmail-m_5287844083015251867gmail_msg">Sounds like we do agree about the glob behavior then, so let me know if you'd like any changes to the latest version of this patch, other than improving documentation. I'm happy to send an updated version as soon as someone is ready to review.</div><div class="gmail-m_5287844083015251867gmail_msg"><br class="gmail-m_5287844083015251867gmail_msg"></div><div class="gmail-m_5287844083015251867gmail_msg">I understand the difference between dir and path (and between the original version of this patch and file) would be that they'd validate the type of entry being matched (so that passing a filename to dir or dir name to file would be an error) - is that what you have in mind? The current matchers don't have a good mechanism to verify the type, so some significant rewiring would need to be done to pass that information down.</div><div class="gmail-m_5287844083015251867gmail_msg">Another thought is that by supporting file and dir, you're incentivizing developers to rely on smarter name collision support (and also case collisions) - one could argue that there's no reason for the complexity caused by that.</div></div></div></div><div dir="ltr" class="gmail-m_5287844083015251867gmail_msg"><div class="gmail_extra gmail-m_5287844083015251867gmail_msg"><div class="gmail_quote gmail-m_5287844083015251867gmail_msg"><div class="gmail-m_5287844083015251867gmail_msg"><br class="gmail-m_5287844083015251867gmail_msg"></div><blockquote class="gmail_quote gmail-m_5287844083015251867gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail-m_5287844083015251867gmail_msg"><div class="gmail-m_5287844083015251867m_-8819813958087893088h5 gmail-m_5287844083015251867gmail_msg"><br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> > IMHO, making patch description explain how recursive matching will be<br class="gmail-m_5287844083015251867gmail_msg">
> > controlled in the future helps reviewers to evaluate your patch.<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
><br class="gmail-m_5287844083015251867gmail_msg">
> I'm happy to update the documentation on my patch to better reflect the<br class="gmail-m_5287844083015251867gmail_msg">
> full-matching characteristic, if it's OK to push a new version of the patch<br class="gmail-m_5287844083015251867gmail_msg">
> :)<br class="gmail-m_5287844083015251867gmail_msg">
><br class="gmail-m_5287844083015251867gmail_msg">
><br class="gmail-m_5287844083015251867gmail_msg">
> > BTW, bikeshedding about name of additional suffix:<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> >   - for non-recursive matching, in "recursive matching by default" case<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> >     - "-eon"<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> >       "end of name matching" is my coined word only for explanation,<br class="gmail-m_5287844083015251867gmail_msg">
> >       and let's choose better one :-)<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> >     - "-exact" for non-recursive matching<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> >       this might confuse developers, because current implementation<br class="gmail-m_5287844083015251867gmail_msg">
> >       already uses "exact" term as "matching without any special<br class="gmail-m_5287844083015251867gmail_msg">
> >       handling".<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> >         <a href="https://selenic.com/repo/hg/file/438173c41587/mercurial/" rel="noreferrer" class="gmail-m_5287844083015251867m_-8819813958087893088cremed gmail-m_5287844083015251867gmail_msg" target="_blank">https://selenic.com/repo/hg/<wbr>file/438173c41587/mercurial/</a><br class="gmail-m_5287844083015251867gmail_msg">
> > match.py#l100<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> >     - "-nonrecursive"<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> >       this is too long, isn't it ?<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> >     - "-file"<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> >       this seems better (short and understandable for end users)<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> >   - for recursive matching, in "non-recursive matching by default" case<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> >     - "-recursive"<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> >       this is too long, isn't it ?<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> >     - "-dir"<br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> >       this seems better (short and understandable for end users)<br class="gmail-m_5287844083015251867gmail_msg">
><br class="gmail-m_5287844083015251867gmail_msg">
><br class="gmail-m_5287844083015251867gmail_msg">
> > > Thanks<br class="gmail-m_5287844083015251867gmail_msg">
> > > Rodrigo<br class="gmail-m_5287844083015251867gmail_msg">
> > ><br class="gmail-m_5287844083015251867gmail_msg">
> > ><br class="gmail-m_5287844083015251867gmail_msg">
> > ><br class="gmail-m_5287844083015251867gmail_msg">
> > > On Mon, Oct 24, 2016 at 6:21 AM, Pierre-Yves David <<br class="gmail-m_5287844083015251867gmail_msg">
> > > <a href="mailto:pierre-yves.david@ens-lyon.org" class="gmail-m_5287844083015251867m_-8819813958087893088cremed gmail-m_5287844083015251867gmail_msg" target="_blank">pierre-yves.david@ens-lyon.org</a><wbr>> wrote:<br class="gmail-m_5287844083015251867gmail_msg">
> > ><br class="gmail-m_5287844083015251867gmail_msg">
> > > ><br class="gmail-m_5287844083015251867gmail_msg">
> > > ><br class="gmail-m_5287844083015251867gmail_msg">
> > > > On 10/21/2016 05:13 PM, FUJIWARA Katsunori wrote:<br class="gmail-m_5287844083015251867gmail_msg">
> > > ><br class="gmail-m_5287844083015251867gmail_msg">
> > > >> At Tue, 18 Oct 2016 10:12:07 -0400,<br class="gmail-m_5287844083015251867gmail_msg">
> > > >> Augie Fackler wrote:<br class="gmail-m_5287844083015251867gmail_msg">
> > > >><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>> On Tue, Oct 18, 2016 at 9:52 AM, Yuya Nishihara <<a href="mailto:yuya@tcha.org" class="gmail-m_5287844083015251867m_-8819813958087893088cremed gmail-m_5287844083015251867gmail_msg" target="_blank">yuya@tcha.org</a>><br class="gmail-m_5287844083015251867gmail_msg">
> > wrote:<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>> On Tue, 18 Oct 2016 09:40:36 -0400, Augie Fackler wrote:<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>>> On Oct 18, 2016, at 09:38, Yuya Nishihara <<a href="mailto:yuya@tcha.org" class="gmail-m_5287844083015251867m_-8819813958087893088cremed gmail-m_5287844083015251867gmail_msg" target="_blank">yuya@tcha.org</a>> wrote:<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>>>><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>>>>> After coordinating on irc to figure out what this proposal<br class="gmail-m_5287844083015251867gmail_msg">
> > actually<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>>>>> is, I've noticed that the semantics of this "exact" proposal are<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>>>>> exactly what "glob" does today, which means (I think) that<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>>>>> "files:foo/bar" should be representable as "glob:foo/bar/*" -<br class="gmail-m_5287844083015251867gmail_msg">
> > what am<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>>>>> I missing?<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>>>>><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>>>><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>>>> Maybe we want a "glob" relative to the repo root?<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>>>><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>>><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>>> As far as I can tell, it already is. "relglob:" is relative to your<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>>> location in the repo according to the docs.<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>>><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>> Unfortunately that isn't.<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>>         'glob:<glob>' - a glob relative to cwd<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>>         'relglob:<glob>' - an unrooted glob (*.c matches C files in<br class="gmail-m_5287844083015251867gmail_msg">
> > all<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>> dirs)<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>> Don't ask me why. ;-)<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>>><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>> Oh wat. It looks like narrowhg might change this behavior in narrowed<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>> repositories, thus my additional confusion.<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>> Maybe we should add "absglob" that is always repo-root-absolute. How<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>> do we feel about that overall?<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>><br class="gmail-m_5287844083015251867gmail_msg">
> > > >><br class="gmail-m_5287844083015251867gmail_msg">
> > > >> FYI, current pattern matching is implemented as below. This was<br class="gmail-m_5287844083015251867gmail_msg">
> > > >> chatted in "non-recursive directory matching" session of 4.0 sprint,<br class="gmail-m_5287844083015251867gmail_msg">
> > > >> and sorry for my late posting of this translation from<br class="gmail-m_5287844083015251867gmail_msg">
> > > >> <a href="http://d.hatena.ne.jp/flying-foozy/20140107/1389087728" rel="noreferrer" class="gmail-m_5287844083015251867m_-8819813958087893088cremed gmail-m_5287844083015251867gmail_msg" target="_blank">http://d.hatena.ne.jp/flying-<wbr>foozy/20140107/1389087728</a> in Japanese,<br class="gmail-m_5287844083015251867gmail_msg">
> > as<br class="gmail-m_5287844083015251867gmail_msg">
> > > >> my backlog of the last sprint.<br class="gmail-m_5287844083015251867gmail_msg">
> > > >><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>   ============ ======= ======= ===========<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>   pattern type root-ed cwd-ed  any-of-path<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>   ============ ======= ======= ===========<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>   wildcard     ---     glob    relglob<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>   regexp       re      ---     relre<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>   raw string   path    relpath ---<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>   ============ ======= ======= ===========<br class="gmail-m_5287844083015251867gmail_msg">
> > > >><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>   If rule is read in from file (e.g. .hgignore):<br class="gmail-m_5287844083015251867gmail_msg">
> > > >><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>     * "glob" is treated as "relglob"<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>     * "re" is treated as "relre"<br class="gmail-m_5287844083015251867gmail_msg">
> > > >><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>   This is mentioned in "hg help patterns" and "hg help hgignore", but<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>   syntax name "relglob" and "relre" themselves aren't explained.<br class="gmail-m_5287844083015251867gmail_msg">
> > > >><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>   "end of name" matching is required:<br class="gmail-m_5287844083015251867gmail_msg">
> > > >><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>     * for glob/relglob as PATTERN (e.g. argument in command line), but<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>     * not for glob/relglob as INCLUDES/EXCLUDES, or other pattern<br class="gmail-m_5287844083015251867gmail_msg">
> > syntaxes<br class="gmail-m_5287844083015251867gmail_msg">
> > > >><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>   For example, file "foo/bar/baz" is:<br class="gmail-m_5287844083015251867gmail_msg">
> > > >><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>     * not matched at "hg files glob:foo/bar"<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>     * but matched at "hg file -I glob:foo/bar"<br class="gmail-m_5287844083015251867gmail_msg">
> > > >><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>   This isn't mentioned in any help document :-<, and the latter seems<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>   to cause the issue mentioned in this patch series.<br class="gmail-m_5287844083015251867gmail_msg"></div></div></blockquote></div></div></div></blockquote><div><br></div><div>`hg help patterns` actually has the following section that I suspect is meant to say this, although it definitely could have been made clearer:</div><div><br></div><div><div>    All patterns, except for "glob:" specified in command line (not for "-I"</div><div>    or "-X" options), can match also against directories: files under matched</div><div>    directories are treated as matched.</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail-m_5287844083015251867gmail_msg"><div class="gmail_extra gmail-m_5287844083015251867gmail_msg"><div class="gmail_quote gmail-m_5287844083015251867gmail_msg"><blockquote class="gmail_quote gmail-m_5287844083015251867gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-m_5287844083015251867gmail_msg"><div class="gmail-m_5287844083015251867m_-8819813958087893088h5 gmail-m_5287844083015251867gmail_msg">
> > > >><br class="gmail-m_5287844083015251867gmail_msg">
> > > >> How about introducing new systematic names like below to re-organize<br class="gmail-m_5287844083015251867gmail_msg">
> > > >> current complicated mapping between names and matching ? (and enable<br class="gmail-m_5287844083015251867gmail_msg">
> > > >> "end of name" matching by "-eon" suffix or so)<br class="gmail-m_5287844083015251867gmail_msg">
> > > >><br class="gmail-m_5287844083015251867gmail_msg">
> > > >>   ============ ======== ======= ===========<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>   pattern type root-ed  cwd-ed  any-of-path<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>   ============ ======== ======= ===========<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>   wildcard     rootglob cwdglob anyglob<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>   regexp       rootre   cwdre   anyre<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>   raw string   rootpath cwdpath anypath<br class="gmail-m_5287844083015251867gmail_msg">
> > > >>   ============ ======== ======= ===========<br class="gmail-m_5287844083015251867gmail_msg">
> > > >><br class="gmail-m_5287844083015251867gmail_msg">
> > > ><br class="gmail-m_5287844083015251867gmail_msg">
> > > > Moving toward a more regular and clear feature set and naming seems a<br class="gmail-m_5287844083015251867gmail_msg">
> > win.<br class="gmail-m_5287844083015251867gmail_msg">
> > > > I'm +1 for moving in that direction.<br class="gmail-m_5287844083015251867gmail_msg">
> > > ><br class="gmail-m_5287844083015251867gmail_msg">
> > > > Cheers,<br class="gmail-m_5287844083015251867gmail_msg">
> > > ><br class="gmail-m_5287844083015251867gmail_msg">
> > > > --<br class="gmail-m_5287844083015251867gmail_msg">
> > > > Pierre-Yves David<br class="gmail-m_5287844083015251867gmail_msg">
> > > ><br class="gmail-m_5287844083015251867gmail_msg">
> > > [2  <text/html; UTF-8 (quoted-printable)>]<br class="gmail-m_5287844083015251867gmail_msg">
> > ><br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
> > ------------------------------<wbr>------------------------------<wbr>----------<br class="gmail-m_5287844083015251867gmail_msg">
> > [FUJIWARA Katsunori]                             <a href="mailto:foozy@lares.dti.ne.jp" class="gmail-m_5287844083015251867m_-8819813958087893088cremed gmail-m_5287844083015251867gmail_msg" target="_blank">foozy@lares.dti.ne.jp</a><br class="gmail-m_5287844083015251867gmail_msg">
> ><br class="gmail-m_5287844083015251867gmail_msg">
<br class="gmail-m_5287844083015251867gmail_msg">
</div></div>------------------------------<wbr>------------------------------<wbr>----------<br class="gmail-m_5287844083015251867gmail_msg">
[FUJIWARA Katsunori]                             <a href="mailto:foozy@lares.dti.ne.jp" class="gmail-m_5287844083015251867m_-8819813958087893088cremed gmail-m_5287844083015251867gmail_msg" target="_blank">foozy@lares.dti.ne.jp</a><br class="gmail-m_5287844083015251867gmail_msg">
</blockquote></div></div></div>
______________________________<wbr>_________________<br class="gmail-m_5287844083015251867gmail_msg">
Mercurial-devel mailing list<br class="gmail-m_5287844083015251867gmail_msg">
<a href="mailto:Mercurial-devel@mercurial-scm.org" class="gmail-m_5287844083015251867gmail_msg" target="_blank">Mercurial-devel@mercurial-scm.<wbr>org</a><br class="gmail-m_5287844083015251867gmail_msg">
<a href="https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel" rel="noreferrer" class="gmail-m_5287844083015251867gmail_msg" target="_blank">https://www.mercurial-scm.org/<wbr>mailman/listinfo/mercurial-<wbr>devel</a><br class="gmail-m_5287844083015251867gmail_msg">
</blockquote></div></div>