Coming to this a bit late but it's still spot on. The global gitignore handles the cross-project stuff perfectly. What I've found since is that there's a middle tier most people skip entirely: .git/info/exclude. Same syntax as .gitignore but scoped to a single repo and never committed. Perfect for when you're testing MCP servers or experimental agent configs that are specific to one project but not ready for the team. Covered the full three-tier hierarchy here: https://blog.stackademic.com/how-to-test-mcp-servers-and-agent-configs-without-annoying-your-team-20692917488d
Counter-argument 1: Different projects need different project-specific gitignores: Rust should ignore target/ and Node should ignore node_modules/. Any tool extension that your project's build pipeline depends on that produces artifacts extends this list. The list is finite and well-defined.
Imagine a Node project starts using Yarn, and Yarn produces some lockfile we don't want committed, now every individual contributor must realize this and extend their system-global gitignore, but only for the correct projects.
Counter-argument 2: A project-specific .gitignore is a tool to lower garbage content in commits by decreasing the effort for inexperienced or lazy collaborators. The .gitignore only needs to contain things actually encountered. For very active Open Source projects, you may want to just put the extra effort into code reviews.
A system-global .gitignore solves a problem for you.
A project-specific .gitignore solves a problem for many people.
> Imagine a Node project starts using Yarn, and Yarn produces some lockfile we don't want committed, now every individual contributor must realize this and extend their system-global gitignore, but only for the correct projects
Good point! Personally I see this as part of the project's git ignore, as I see it as the project's tool, but as one dev could use npm and another yarn - I get this is more complicated than I thought HAHA LOL
Thank you for both counter-arguments, they are definitely food for thought!
Coming to this a bit late but it's still spot on. The global gitignore handles the cross-project stuff perfectly. What I've found since is that there's a middle tier most people skip entirely: .git/info/exclude. Same syntax as .gitignore but scoped to a single repo and never committed. Perfect for when you're testing MCP servers or experimental agent configs that are specific to one project but not ready for the team. Covered the full three-tier hierarchy here: https://blog.stackademic.com/how-to-test-mcp-servers-and-agent-configs-without-annoying-your-team-20692917488d
Thanks for reading and your feedback. Git is very powerful with so many configuration options, so great to know of alternative ways.
Always a pleasure :)
Good one, Eddie
Thank you Pradumna
Counter-argument 1: Different projects need different project-specific gitignores: Rust should ignore target/ and Node should ignore node_modules/. Any tool extension that your project's build pipeline depends on that produces artifacts extends this list. The list is finite and well-defined.
Imagine a Node project starts using Yarn, and Yarn produces some lockfile we don't want committed, now every individual contributor must realize this and extend their system-global gitignore, but only for the correct projects.
Counter-argument 2: A project-specific .gitignore is a tool to lower garbage content in commits by decreasing the effort for inexperienced or lazy collaborators. The .gitignore only needs to contain things actually encountered. For very active Open Source projects, you may want to just put the extra effort into code reviews.
A system-global .gitignore solves a problem for you.
A project-specific .gitignore solves a problem for many people.
Thank you for reading and the great reply Simon!
> Imagine a Node project starts using Yarn, and Yarn produces some lockfile we don't want committed, now every individual contributor must realize this and extend their system-global gitignore, but only for the correct projects
Good point! Personally I see this as part of the project's git ignore, as I see it as the project's tool, but as one dev could use npm and another yarn - I get this is more complicated than I thought HAHA LOL
Thank you for both counter-arguments, they are definitely food for thought!