← Back to context

Comment by kodablah

1 day ago

This mindset is how you get lots of IDE/dev-env-specific/platform-specific cruft inside of repos instead of pristine repos. It makes both contribution and maintenance difficult over time. While less of an extreme issue as IDE/dev-env-specific/platform-specific hacks/scripts littering the repo, gitignore entries should be generally justifiable, not ever-growing cruft to be added by each developer specific to their situation.

I add .DS_Store to every repo despite also having it ignored globally. Efficiency beats pristine. I don't want to have to ever think about or deal with it at all.

  • > Efficiency beats pristine. _I_ don't want [...]

    Emphasis mine. This is the exact mindset I'm referring to, and when applied generally to files in the repo, will bite at some point. Even if you're lucky and it's unimportant/internal enough not to bite users, it will bite contributors. Luckily none of us would be discourteous enough to do this while contributing to another's repo.

    • If it's my repo then I decide which files are tracked and I don't want any .DS_Store files, nor do I think any person in history has ever intended to track a .DS_Store file.

      In a perfect world everyone would add .DS_Store to their global ignore list but since this is not default it necessitates defensive measures.

      If you don't add it to .gitignore then I can guarantee at some point a .DS_Store file will be committed to the repo, because the behavior is broken by default.