4 Comments

Good one, Eddie

Expand full comment
author

Thank you Pradumna

Expand full comment
Aug 18·edited Aug 18Liked by Eddie Jaoude

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.

Expand full comment
author

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!

Expand full comment