On 28/10/16 10:04, Jeff King wrote: > 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.
Precisely. >> 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. You raise a good point about the requirement. I was about to make an argument in favour of it, but I argued myself out of an argument. I will say; why have it work in one place and not others?
