On Thu, Oct 27, 2016 at 12:48:34PM -0700, Jacob Keller wrote: > > 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.
One thing I will say about this approach is that you can implement it without any changes in git by doing: path=.git/info/exclude cat $path.d/* >$path and I have seen several config mechanisms basically do that (e.g., Debian packaging for a program that doesn't have its own ".d" mechanism, but needs to grab config provided by several separate packages). The reason to teach that trick to git is convenience; you don't have to remember to build the master file from its parts because it's done dynamically whenever git needs to look at it. > 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 I'm not convinced this is needed for in-repo .gitignore files. The point is that you are pulling together separate files that may be administered independently. But git repositories inherently have a whole-project view. I'm not sure that separate files buy you a lot there. And the compatibility issues are more complicated. I do agree that: cd .git/info git clone /my/exclude/repo exclude ;# or exclude.d should work; ignoring dotfiles when reading the directory solves that, and is a pretty standard solution. -Peff
