[PATCH 7 of 8] ignore: add support for including subdir .hgignores

[Martin von Zweigbergk]

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?

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.

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.

On Fri, May 15, 2015, 03:23 Martin Geisler <martin at geisler.net> wrote:

> Durham Goode <durham at fb.com> writes:
>
> > At the moment we only support globs in sub-ignore files. regexs will
> > cause an exception. This is because we can't reliabily modify a regex
> > to have a prefix (ex: adding a prefix to '^foo|^bar' would require
> > parsing the regex).
>
> That is surprising from a high-level since regular languages are closed
> under concatenation.
>
> However, I see what you're saying: blindly adding a prefix to a regex
> doesn't do what you expect. I didn't look at the mechanics of the code,
> but if you could strip off the path elements as you descend down the
> directory tree, you should get the right behavior.
>
> So if we have
>
>   root/sub-dir/foo/
>                bar/
>                .hgignore <- '^foo|^bar'
>                baz.txt
>        .hgignore <- '#include sub-dir/.hgignore'
>
> then don't match
>
>   sub-dir/foo/
>   sub-dir/bar/
>
> against
>
>   sub-dir/(^foo|^bar)
>
> Instead match
>
>   foo/
>   bar/
>
> against
>
>   ^foo|^bar
>
> to conclude the directories should be ignored.
>
> Maybe that's not what you want if you intend to make one big regular
> expression upfront and run all paths through that.
>
> --
> Martin Geisler
>
> http://google.com/+MartinGeisler
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150515/0bb17447/attachment.html>