<p dir="ltr">I agree with the other Martin. I'm not at a computer now, so it's hard to check, but where are the ignore patterns used? I know it's used while walking the working copy in dirstate.py. I would think that that piece of code would not mind if it had to create a new union matcher every time it visited a subdirectory mentioned in an include. Would applying the matcher to only the path within the subdirectory be a problem performance-wise?</p>
<p dir="ltr">Are the .hgignore files always read from the working copy? If not, it would be nice to not have to read all the submanifests (when using such) for operations that care only about some subdirectory.</p>
<p dir="ltr">Also, does the subdirectory .hgignore have to be called exactly .hgignore? I'm just wondering at this point; I haven't decided whether I think it should be required or not.<br>
</p>
<br><div class="gmail_quote">On Fri, May 15, 2015, 03:23 Martin Geisler <<a href="mailto:martin@geisler.net">martin@geisler.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Durham Goode <<a href="mailto:durham@fb.com" target="_blank">durham@fb.com</a>> writes:<br>
<br>
> At the moment we only support globs in sub-ignore files. regexs will<br>
> cause an exception. This is because we can't reliabily modify a regex<br>
> to have a prefix (ex: adding a prefix to '^foo|^bar' would require<br>
> parsing the regex).<br>
<br>
That is surprising from a high-level since regular languages are closed<br>
under concatenation.<br>
<br>
However, I see what you're saying: blindly adding a prefix to a regex<br>
doesn't do what you expect. I didn't look at the mechanics of the code,<br>
but if you could strip off the path elements as you descend down the<br>
directory tree, you should get the right behavior.<br>
<br>
So if we have<br>
<br>
  root/sub-dir/foo/<br>
               bar/<br>
               .hgignore <- '^foo|^bar'<br>
               baz.txt<br>
       .hgignore <- '#include sub-dir/.hgignore'<br>
<br>
then don't match<br>
<br>
  sub-dir/foo/<br>
  sub-dir/bar/<br>
<br>
against<br>
<br>
  sub-dir/(^foo|^bar)<br>
<br>
Instead match<br>
<br>
  foo/<br>
  bar/<br>
<br>
against<br>
<br>
  ^foo|^bar<br>
<br>
to conclude the directories should be ignored.<br>
<br>
Maybe that's not what you want if you intend to make one big regular<br>
expression upfront and run all paths through that.<br>
<br>
--<br>
Martin Geisler<br>
<br>
<a href="http://google.com/+MartinGeisler" target="_blank">http://google.com/+MartinGeisler</a><br>
_______________________________________________<br>
Mercurial-devel mailing list<br>
<a href="mailto:Mercurial-devel@selenic.com" target="_blank">Mercurial-devel@selenic.com</a><br>
<a href="http://selenic.com/mailman/listinfo/mercurial-devel" target="_blank">http://selenic.com/mailman/listinfo/mercurial-devel</a><br>
</blockquote></div>