Re: Expanding Includes in .gitignore

From: Alexei Lozovsky <a.lozovsky@gmail.com>
Date: Oct 27, 2016, 08:19 UTC
Message-ID: <CALhvvbYqeWw+q=TPxTpve6JKoy0URYeWxj2vVOnzrA_g3Z3esA@mail.gmail.com>
In-Reply-To: <80919456-7563-2c16-ba23-ce4fcc2777de@pelly.co>

> 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 think the rc.d-like approach with directories is better as it does not add new magical filenames (what if I absolutely do need to name my directories ". path", with a space? :) keeping the syntax of gitignores themselves simple, and allowing us to think of files as still being separate entities. This can be useful for the following case:

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

As I understand, the precedence only matters for negative patterns (the ones that start with an exclamation mark, !). For example, suppose you have files 'foo1' and 'foo2'. This .gitignore

    foo*
    !foo1

will ignore foo2, but will show foo1. However, if the lines are swapped:

    !foo1
    foo*

then both foo1 and foo2 will be ignored.

Now, if we consider the case of multiple .gitignore files, it could be unexpected and possibly annoying for negative patterns in one file to affect the patterns added by some other files. I would find it more conceptually simple to apply individual .gitignores one by one, as opposed to parsing them all and creating one giant exclusion rule. (In technical terms, this means keeping one struct exclude_list for each .gitignore, not merging them all into one single list.)

In this case there should be no precendence problems as applied gitignores only add new ignored files, without un-ignoring anything previously ignored by other files.

However, if we allow textual inclusion, then it means that we can put a gitignore into our gitignore so that we can unignore while we ignore, which again brings us the question of whether it is actually needed and expected.

> I would like to know the desirability/practicality/stupidity of such a
> feature as I believe it is within my skillset to implement it.

In my mind, this feature definitely has utility and it can be implemented in backwards-compatible way, so why not.

However, I do not recall any precendent of git using rc.d-like configs. And some can argue that your goal can be achieved by generating the .gitignore by some external means and symlinking the result into .git/info/exclude, so this is not Git's problem and we should not be overcomplicating things with something as simple as a list exclude patterns. This line of argument also can be used to opposes any textual inclusion as well, because it can be expanded into 'why don't we add a Turing-complete programming language then to specify the patterns to ignore'.