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

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

[ZH L]

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.

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.

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

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

[brian m. carlson]

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

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

[ZH L]

Thank you for your detailed and thorough explanation; it has been very
helpful in understanding the issue.

I completely agree with your point that editor-related ignore rules
should be handled by individuals, not included in the project
repository. Since each developer uses different editors, enforcing
editor-specific ignore rules at the project level would indeed
introduce unnecessary complexity.

The backward compatibility concern you raised made me realize that
even if Git 3.0 introduces this feature, there would still be a risk
of mistakenly committing files due to different Git versions in use
across environments. This is definitely a practical issue that cannot
be overlooked.

The reason I raised this question wasn't to strongly push for the
introduction of multiple named ignore files, but to understand whether
this idea had already been considered and whether there are any
fundamental design objections. Your response has clarified that the
main concerns are compatibility risks and a lack of demand, rather
than technical feasibility.

I also agree that if Git were to evolve in this direction in the
future, an explicit include syntax or pragma configuration would be
easier to manage and would better ensure backward compatibility. Such
changes might only be feasible after Git 3.0.

Once again, thank you for your patient explanation and in-depth
analysis of this topic, which has provided me with valuable background
information.


On Wed, Jan 28, 2026 at 10:14 AM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> 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