{"thread":{"id":"64877","subject":"Question: supporting multiple named ignore files (in addition to .gitignore)","startedAt":"2026-01-28T00:42:25Z","lastAt":"2026-01-28T10:13:38Z","messageCount":3,"participants":["ZH L","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"534738","messageId":"CA+5Chmhwcz=gOQHW18_w+uYojshjFj8MCE+srUpJgEhbh8J09w@mail.gmail.com","threadId":"64877","inReplyTo":null,"subject":"Question: supporting multiple named ignore files (in addition to .gitignore)","fromName":"ZH L","fromEmail":"lzh2587379717@gmail.com","sentAt":"2026-01-28T00:42:12Z","receivedAt":"2026-01-28T00:42:25Z","isPatch":false,"sender":{"key":"lzh2587379717@gmail.com","avatar":null},"body":"Today Git only loads ignore rules from .gitignore (plus global and\ninfo/exclude),\nwhich works well but can become hard to maintain in large repositories where\neditor, build, and miscellaneous rules are mixed into a single file.\n\nWould the Git project consider supporting additional named ignore files\n(for example editor.gitignore, build.gitignore) that are automatically merged\nwith .gitignore, with a well-defined and documented precedence order?\n\nThis would allow semantic separation of ignore rules while keeping full backward\ncompatibility, and could reduce the need for external scripts that currently\nexist solely to generate .gitignore.\n\nI’m mainly interested in whether this idea has been considered before, and\nwhether the maintainers see fundamental design objections to it.\n"},{"id":"534740","messageId":"aXlw-RN82f3CquNH@fruit.crustytoothpaste.net","threadId":"64877","inReplyTo":"CA+5Chmhwcz=gOQHW18_w+uYojshjFj8MCE+srUpJgEhbh8J09w@mail.gmail.com","subject":"Re: Question: supporting multiple named ignore files (in addition to .gitignore)","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2026-01-28T02:14:17Z","receivedAt":"2026-01-28T02:21:46Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2026-01-28 at 00:42:12, ZH L wrote:\n> Today Git only loads ignore rules from .gitignore (plus global and\n> info/exclude),\n> which works well but can become hard to maintain in large repositories where\n> editor, build, and miscellaneous rules are mixed into a single file.\n\nIt's also possible to put `.gitignore` files into subdirectories if\nthat's more convenient.  But yes, there's basically one per directory.\n\nI want to also point out that editor ignore rules belong in personal\nignore files, not in projects.  I use Neovim, and if I had swap files\nenabled, it would be my personal responsibility to ignore those, just\nlike any other editor files, so as not to leave or check in detritus to\nthe repository[0].  Similarly, I'm confident that Junio, the maintainer,\nhas Emacs backup files ignored or disabled.  A project cannot possibly\naccount for all the possible editors one might use to contribute to it,\nso it's better for each contributor to be responsible for their own\neditor, which means that those rules only have to be set once, not per\nproject.\n\n> Would the Git project consider supporting additional named ignore files\n> (for example editor.gitignore, build.gitignore) that are automatically merged\n> with .gitignore, with a well-defined and documented precedence order?\n> \n> This would allow semantic separation of ignore rules while keeping full backward\n> compatibility, and could reduce the need for external scripts that currently\n> exist solely to generate .gitignore.\n\nThis wouldn't actually be backwards compatible.  Say Git 3.0 added this\nsupport, but someone continued to use Git 2.50 (because they're on an\nLTS distribution).  Git 2.50 wouldn't honour those files, so it would be\npossible for users to check in files that were only ignored by the new\nrules.  I assure you that there are many people using very old versions\nof Git and that even in corporate environments, there are a wide variety\nof Git versions in use.\n\nThat doesn't mean we couldn't implement this functionality, but I have\nnot yet seen a project that needs it.  Many modern languages put all\nbuild products in one directory, and if the `.gitignore` file contains\nonly the necessary rules (instead of combining multiple large template\nfiles), it can usually be pretty small[1].\n\nI'm of course interested in what other folks think about such a\nproposal.\n\n> I’m mainly interested in whether this idea has been considered before, and\n> whether the maintainers see fundamental design objections to it.\n\nI don't know whether this specific policy has been requested before, but\nwe did recently see\nhttps://lore.kernel.org/git/LV8P220MB2017EA88974F2311DCFB7665F52AA@LV8P220MB2017.NAMP220.PROD.OUTLOOK.COM/.\n\nBetween the proposal requested here and the one I linked above, I would\nprefer an approach that provides for explicit inclusion syntax, since I\nwould think that would be easier to reason about and more flexible, but\ndoing so in the least backwards incompatible way would be difficult.\nPerhaps we could make the first line something that contains a special\npragma (e.g., `#/gitignore pragma on`) to turn on a new syntax.\n\nEven if this were implemented, we'd probably want to do so in Git 3.0,\nwhich is coming up soon, and we'd need someone to do the design and\nimplementation.\n\n[0] In my particular case, I have turned swap files off because I find\nthe way they work and the detritus they leave behind annoying.\n[1] Go has 53 lines, Rust has 79, Neovim has 87, Git has 260, and Emacs\nhas 383.  Git could have many fewer if we built our binaries into a\nbuild directory, though.  Emacs probably could as well.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"534750","messageId":"CA+5Chmiz32zVTao61JS2eR_6WBenYNcPj0JvmcAtZBep1Z5Z-Q@mail.gmail.com","threadId":"64877","inReplyTo":"aXlw-RN82f3CquNH@fruit.crustytoothpaste.net","subject":"Re: Question: supporting multiple named ignore files (in addition to .gitignore)","fromName":"ZH L","fromEmail":"lzh2587379717@gmail.com","sentAt":"2026-01-28T10:13:26Z","receivedAt":"2026-01-28T10:13:38Z","isPatch":false,"sender":{"key":"lzh2587379717@gmail.com","avatar":null},"body":"Thank you for your detailed and thorough explanation; it has been very\nhelpful in understanding the issue.\n\nI completely agree with your point that editor-related ignore rules\nshould be handled by individuals, not included in the project\nrepository. Since each developer uses different editors, enforcing\neditor-specific ignore rules at the project level would indeed\nintroduce unnecessary complexity.\n\nThe backward compatibility concern you raised made me realize that\neven if Git 3.0 introduces this feature, there would still be a risk\nof mistakenly committing files due to different Git versions in use\nacross environments. This is definitely a practical issue that cannot\nbe overlooked.\n\nThe reason I raised this question wasn't to strongly push for the\nintroduction of multiple named ignore files, but to understand whether\nthis idea had already been considered and whether there are any\nfundamental design objections. Your response has clarified that the\nmain concerns are compatibility risks and a lack of demand, rather\nthan technical feasibility.\n\nI also agree that if Git were to evolve in this direction in the\nfuture, an explicit include syntax or pragma configuration would be\neasier to manage and would better ensure backward compatibility. Such\nchanges might only be feasible after Git 3.0.\n\nOnce again, thank you for your patient explanation and in-depth\nanalysis of this topic, which has provided me with valuable background\ninformation.\n\n\nOn Wed, Jan 28, 2026 at 10:14 AM brian m. carlson\n<sandals@crustytoothpaste.net> wrote:\n>\n> On 2026-01-28 at 00:42:12, ZH L wrote:\n> > Today Git only loads ignore rules from .gitignore (plus global and\n> > info/exclude),\n> > which works well but can become hard to maintain in large repositories where\n> > editor, build, and miscellaneous rules are mixed into a single file.\n>\n> It's also possible to put `.gitignore` files into subdirectories if\n> that's more convenient.  But yes, there's basically one per directory.\n>\n> I want to also point out that editor ignore rules belong in personal\n> ignore files, not in projects.  I use Neovim, and if I had swap files\n> enabled, it would be my personal responsibility to ignore those, just\n> like any other editor files, so as not to leave or check in detritus to\n> the repository[0].  Similarly, I'm confident that Junio, the maintainer,\n> has Emacs backup files ignored or disabled.  A project cannot possibly\n> account for all the possible editors one might use to contribute to it,\n> so it's better for each contributor to be responsible for their own\n> editor, which means that those rules only have to be set once, not per\n> project.\n>\n> > Would the Git project consider supporting additional named ignore files\n> > (for example editor.gitignore, build.gitignore) that are automatically merged\n> > with .gitignore, with a well-defined and documented precedence order?\n> >\n> > This would allow semantic separation of ignore rules while keeping full backward\n> > compatibility, and could reduce the need for external scripts that currently\n> > exist solely to generate .gitignore.\n>\n> This wouldn't actually be backwards compatible.  Say Git 3.0 added this\n> support, but someone continued to use Git 2.50 (because they're on an\n> LTS distribution).  Git 2.50 wouldn't honour those files, so it would be\n> possible for users to check in files that were only ignored by the new\n> rules.  I assure you that there are many people using very old versions\n> of Git and that even in corporate environments, there are a wide variety\n> of Git versions in use.\n>\n> That doesn't mean we couldn't implement this functionality, but I have\n> not yet seen a project that needs it.  Many modern languages put all\n> build products in one directory, and if the `.gitignore` file contains\n> only the necessary rules (instead of combining multiple large template\n> files), it can usually be pretty small[1].\n>\n> I'm of course interested in what other folks think about such a\n> proposal.\n>\n> > I’m mainly interested in whether this idea has been considered before, and\n> > whether the maintainers see fundamental design objections to it.\n>\n> I don't know whether this specific policy has been requested before, but\n> we did recently see\n> https://lore.kernel.org/git/LV8P220MB2017EA88974F2311DCFB7665F52AA@LV8P220MB2017.NAMP220.PROD.OUTLOOK.COM/.\n>\n> Between the proposal requested here and the one I linked above, I would\n> prefer an approach that provides for explicit inclusion syntax, since I\n> would think that would be easier to reason about and more flexible, but\n> doing so in the least backwards incompatible way would be difficult.\n> Perhaps we could make the first line something that contains a special\n> pragma (e.g., `#/gitignore pragma on`) to turn on a new syntax.\n>\n> Even if this were implemented, we'd probably want to do so in Git 3.0,\n> which is coming up soon, and we'd need someone to do the design and\n> implementation.\n>\n> [0] In my particular case, I have turned swap files off because I find\n> the way they work and the detritus they leave behind annoying.\n> [1] Go has 53 lines, Rust has 79, Neovim has 87, Git has 260, and Emacs\n> has 383.  Git could have many fewer if we built our binaries into a\n> build directory, though.  Emacs probably could as well.\n> --\n> brian m. carlson (they/them)\n> Toronto, Ontario, CA\n"}]}