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