Re: Question: supporting multiple named ignore files (in addition to .gitignore)

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 3731 bytes --]

On 2026-01-28 at 00:42:12, ZH L wrote:
> Today Git only loads ignore rules from .gitignore (plus global and
> info/exclude),
> which works well but can become hard to maintain in large repositories where
> editor, build, and miscellaneous rules are mixed into a single file.

It's also possible to put `.gitignore` files into subdirectories if
that's more convenient.  But yes, there's basically one per directory.

I want to also point out that editor ignore rules belong in personal
ignore files, not in projects.  I use Neovim, and if I had swap files
enabled, it would be my personal responsibility to ignore those, just
like any other editor files, so as not to leave or check in detritus to
the repository[0].  Similarly, I'm confident that Junio, the maintainer,
has Emacs backup files ignored or disabled.  A project cannot possibly
account for all the possible editors one might use to contribute to it,
so it's better for each contributor to be responsible for their own
editor, which means that those rules only have to be set once, not per
project.

> Would the Git project consider supporting additional named ignore files
> (for example editor.gitignore, build.gitignore) that are automatically merged
> with .gitignore, with a well-defined and documented precedence order?
> 
> This would allow semantic separation of ignore rules while keeping full backward
> compatibility, and could reduce the need for external scripts that currently
> exist solely to generate .gitignore.

This wouldn't actually be backwards compatible.  Say Git 3.0 added this
support, but someone continued to use Git 2.50 (because they're on an
LTS distribution).  Git 2.50 wouldn't honour those files, so it would be
possible for users to check in files that were only ignored by the new
rules.  I assure you that there are many people using very old versions
of Git and that even in corporate environments, there are a wide variety
of Git versions in use.

That doesn't mean we couldn't implement this functionality, but I have
not yet seen a project that needs it.  Many modern languages put all
build products in one directory, and if the `.gitignore` file contains
only the necessary rules (instead of combining multiple large template
files), it can usually be pretty small[1].

I'm of course interested in what other folks think about such a
proposal.

> I’m mainly interested in whether this idea has been considered before, and
> whether the maintainers see fundamental design objections to it.

I don't know whether this specific policy has been requested before, but
we did recently see
https://lore.kernel.org/git/LV8P220MB2017EA88974F2311DCFB7665F52AA@LV8P220MB2017.NAMP220.PROD.OUTLOOK.COM/.

Between the proposal requested here and the one I linked above, I would
prefer an approach that provides for explicit inclusion syntax, since I
would think that would be easier to reason about and more flexible, but
doing so in the least backwards incompatible way would be difficult.
Perhaps we could make the first line something that contains a special
pragma (e.g., `#/gitignore pragma on`) to turn on a new syntax.

Even if this were implemented, we'd probably want to do so in Git 3.0,
which is coming up soon, and we'd need someone to do the design and
implementation.

[0] In my particular case, I have turned swap files off because I find
the way they work and the detritus they leave behind annoying.
[1] Go has 53 lines, Rust has 79, Neovim has 87, Git has 260, and Emacs
has 383.  Git could have many fewer if we built our binaries into a
build directory, though.  Emacs probably could as well.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]