Hacker News new | ask | show | jobs
by Anon1096 44 days ago
You frequently having to tell people about a global configuration gitignore is an obvious consequence of "My general rule is that in-repo .gitignore should only be used for repo-specific things". It wastes less of everyone's time to just gitignore them in every project.
4 comments

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.

but you do think about it when you add it to every repo?
Arguably git should ignore this file by default. 99% of the time it shouldn't be automatically picked up when you want to make a commit.
It would also be nice if Finder stopped generating .DS_Store files and moved that information to metadata on the directory! They had a great opportunity to fix this when they introduced APFS but alas the blight continues.
Arguably it does: Every default .gitignore I’ve ever seen has included it.
Every time I've requested changes to a pull request because the reviewee didn't know the difference between .gitignore and .config/git/ignore, the reviewee appreciated learning about the feature. The person you're replying to also clearly said their reviewees are pleasantly surprised, so it hardly seems like a waste of time. Also consider that it takes almost no effort on our part to point out this feature, no effort for them to learn it because we tell them directly, and it happens at most once per new contributor or hire.
I’d really only like my projects to talk about things relevant to the project, instead of having to think about the fact that you might be using Qt Creator.
Eh. It's a tool, not a document. It should contain things that help development.
Fair, but it depends how uniform the culture is around a particular project. Is it haskell and everyone is using emacs? Sure, include those. But trying to chase the requirements of half a dozen different editors is silly.
That's the thing though, you don't need to do that. Whoever is using whatever editor can do it, so the effort is distributed to whoever cares to contribute.

There is no meaningful penalty for it to be not up-to-date. There is only a benefit for people who come in when it's already configured, as they don't need to configure anything anymore.

(I say that but I'm using a global ignore too for eg ai configuration like skills as I like to half-ass them before discarding again)

The penalty is a long file full of cruft that's effectively impossible to ever clean up.