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

From: ZH L <lzh2587379717@gmail.com>
Date: Jan 28, 2026, 10:13 UTC
Message-ID: <CA+5Chmiz32zVTao61JS2eR_6WBenYNcPj0JvmcAtZBep1Z5Z-Q@mail.gmail.com>
In-Reply-To: <aXlw-RN82f3CquNH@fruit.crustytoothpaste.net>

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:

Show 72 quoted lines

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