On Thu, Oct 27, 2016 at 3:50 AM, Jeff King <p...@peff.net> wrote: > 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. >
Agreed, this seems useful to me. >> 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. Yep that would be easier and simpler. > >> 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/*". Yea, this is the normal behavior, and the user is expected to order their files lexically such as "00-name", "50-name" and so on. Pretty traditional for a lot of newer configurations. > > 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. > Yea if you have these inter-dependent relationships it can't be expressed, but then neither can it really be expressed in the simple "include" case above. I would strongly prefer rc.d style directories either with a "if the .gitignore is a directory treat it like rc.d" or even "add support for .gitignore.d as well as .gitignore" One thing to keep in mind would be that we should make sure we can handle the .gitignore being a submodule or a git repository, so that users could just do something like "git submodule add <repo> .gitignore and then track git ignore contents from a repository in a nice way. By this I mean that the reading of files in .gitignore directory should exclude reading .git or other hidden files in some documented manor so as to avoid problems when linking to a git directory for its contents. Thanks, Jake > -Peff
