Re: Expanding Includes in .gitignore

From: Jeff King <peff@peff.net>
Date: Oct 27, 2016, 21:04 UTC
Message-ID: <20161027210458.ptzh4y75dkfaixeo@sigill.intra.peff.net>
In-Reply-To: <CA+P7+xqmVM-bEc7sZcn+p3qhFUUJvC+rko7CYu+KgyTAeiOifw@mail.gmail.com>

On Thu, Oct 27, 2016 at 12:48:34PM -0700, Jacob Keller wrote:

Show 8 quoted lines

> > 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