<div dir="ltr">Unfortunately, while set would match the right files, because of the way the code is structured, it provides no way to not try visiting the directories inside the non-recursive match - the set needs to first collect all the files in all subdirectories (match.py, _expandset) and then filter that down to the desired ones. In plain hg repos, that's just much slower - in the context of narrowhg, the repo will simply not have the manifests for those subdirectories and trying to visit them will crash.<div><div><br></div><div>The follow-up change to this one (which I haven't sent yet but is written) is updating visitdir to allow non-recursiveness, which btw makes something like "hg files -I rootglob:browser/*" about 4-5x faster in the firefox repo.<br><div><div><div><div><div><br></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 16, 2016 at 6:21 AM, Pierre-Yves David <span dir="ltr"><<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank">pierre-yves.david@ens-lyon.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On 12/16/2016 02:19 AM, Augie Fackler wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Nov 24, 2016, at 10:28 AM, FUJIWARA Katsunori <<a href="mailto:foozy@lares.dti.ne.jp" target="_blank">foozy@lares.dti.ne.jp</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes, "files:" was the original version of this patch and the case I really<br>
care about :) I changed it to rootglob after your comments.<br>
Which way would be preferred to move forward?<br>
</blockquote></blockquote>
<br>
"files:" is "path:" family, and "rootglob:" is "glob:" family. As we<br>
concluded before, "path:" itself can't control recursion of matching<br>
well.<br>
<br>
Therefore, I think that "files:" should be implemented if needed,<br>
regardless of implementing "rootglob:".<br>
<br>
Of course, we need high point view of this area, at first :-)<br>
<br>
<br>
BTW, it is a little ambiguous (at least, for me) that "files:foo"<br>
matches against both file "foo" and files just under directory<br>
"foo". Name other than "files:" may resolve this ambiguity, but I<br>
don't have any better (and short enough) name :-<<br>
<br>
 ========== ==== ======= ===========<br>
 pattern    foo  foo/bar foo/bar/baz<br>
 ========== ==== ======= ===========<br>
 path:foo    o     o         o<br>
<br>
 files:foo   o     o         x<br>
<br>
 file:foo    o     x         x<br>
 dir:foo     x     o         o<br>
 ========== ==== ======= ===========<br>
<br>
</blockquote>
<br>
Scanning the plan page, I see that there’s a *lot* of work that could be done and no consensus as yet, but that the only immediate use case seems to be the rootfile/rootglob case. Is there some path forward we could agree on that would unblock those immediate needs for narrowhg and not make things harder in the future?<br>
<br>
Alternatively, would we be okay with a slight refactor of the matcher so that narrowhg can introduce a custom filesonly: matcher for the time being so we can keep making forward progress there?  I don’t know the matcher code well enough to be able to guess if this is a reasonable path so we can be unblocked.<br>
<br>
(It’s very hard for to justify the amount of work implied by reaching consensus on FileNamePatternsPlan and then executing the entire thing when what we need is solvable today with a sub-hour patch to existing code, thus my trying to find a solution we can all live with.)<br>
</blockquote>
<br></div></div>
As far as I understand, Foozy finding shows that the feature narrowhg needs is already there and nothing new is necessary.<br>
<br>
You can add "set:" in front of your glob to make it non recursive in all cases "set:your/directory/you/want/t<wbr>o/match/files/in/*"<br>
<br>
If this does not fits your needs, this probably mean I got your usecase wrong. In that case can you re-explain the issue you are trying to solve here?<br>
<br>
<br>
At the project level, it will make sense to clean up the Pattern Matching at some point, and Foozy wiki work will help us to do that.<br>
<br>
Cheers.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Pierre-Yves David<br>
</font></span></blockquote></div><br></div>