On Thu, Oct 27, 2016 at 01:22:43PM +1300, Aaron Pelly wrote: > The use case for this is where I did not write my own rules, but I want > to keep them updated. https://github.com/github/gitignore is a damn good > resource, but I want to pull it and include relevant bits project by > project and/or system wide. I don't want to have to update many projects > manually if that, or any other, repo changes. That seems like a reasonable thing to want. > A very brief look at dir.c would indicate that a recursive call from > add_excludes to itself when it parses some sort of include tag would do > it within a file. I'm sure it'd be pretty straight forward to hook into > something in dir.c to parse directories too. > > I'm thinking something like ". path/to/include/file" in an ignore file, > and/or creating .gitignore.d and/or allowing $HOME/.config/git/ignore > and $GIT_DIR/info/exclude to be directories. Or some sane and consistent > mixture of these things. I'd shy away from an actual include directive, as it raises a lot of complications: - as you noted, cycles in the include graph need to be detected and broken - we parse possibly-hostile .gitignore files from cloned repositories. What happens when I include ask to include /etc/passwd? Probably nothing, but there are setups where it might matter (e.g., something like Travis that auto-builds untrusted repositories, and you could potentially leak the contents of files via error messages). It's nice to avoid the issue entirely. - finding a backwards-compatible syntax Whereas letting any of the user- or repo-level exclude files be a directory, and simply reading all of the files inside, seems simple and obvious. If you go that route, it probably makes sense to teach gitattributes the same trick. > In the case of a directory the plan would be to add links to files > stored/sourced elsewhere. This does pose a precedence question which I > haven't thought about yet, but probably makes it too hard for the > limited value it brings. I think the normal behavior in such "foo.d" directory is to just sort the contents lexically and read them in order, as if they were all concatenated together, and with no recursion. I.e., behave "as if" the user had run "cat $dir/*". That lets you handle precedence via the filenames (or symlink names). It can't handle all cases (some items in "00foo" want precedence over "01bar" and vice versa), but I don't think there's an easy solution. That's a good sign that one or more of the files should be broken up. -Peff