Re: Expanding Includes in .gitignore

From: Duy Nguyen <pclouds@gmail.com>
Date: Oct 30, 2016, 03:09 UTC
Message-ID: <CACsJy8AMDW2w=xnAYDLTEN5MVxj+5JuiFnXGD1JFbD=RgLDcfA@mail.gmail.com>
In-Reply-To: <20161027210458.ptzh4y75dkfaixeo@sigill.intra.peff.net>

On Fri, Oct 28, 2016 at 4:04 AM, Jeff King <peff@peff.net> wrote:

Show 20 quoted lines

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

My first thought at this .git/info/exclude.d was "oh no I have to teach untracked cache about new dependencies, or at least disable it until it can deal with exclude.d", but this "cat" approach simplifies things and should keep untracked cache unchanged.

There may be complication with negative patterns though. The user may want to limit the effect of negative patterns within individual exclude files in exclude.d so a negative pattern in exclude.d/a won't influence anything in exclude.d/b (easier to reason, safer to compose different exclude sets). The plain "cat" would lose file boundary info that we need. I'm not sure. But I'll dig more into it when patches show up.

-- 
Duy