alt Hacker NewsThe global/user wide exclude is a feature that should be more widely known. I frequently have people submitting changes to add their IDE/OS/AI/... files to every project's .gitignore. They are almost always pleasantly surprised when I tell them that they can add them to their standard configuration and have them ignored everywhere without bothering every project and without risk of accidentally committing them on a project where they haven't updated the .gitignore yet.
My general rule is that in-repo .gitignore should only be used for repo-specific things (build outputs, dependency folders, ...) and most user tools should be in their own user config.
Replies
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.
Or if your editor is happy to store them in a subfolder that is useful. I use Sublime with the AutoProjects extension and it puts .sublime-project snd .sublime-workspace under a .sublime folder that I can have a .gitignore * underneath.
I'd rather have a pristine repo (no .ds_store/.idea/etc) than a pristine .gitignore file.
I prefer gitignore since it survives dev container rebuilds.
I can set a creation script or volume to restore/persist configs if I must avoid gitignore. However, that's an extra script or devcontainer mounts config over a gitignore line.
Do you not see the conflict between seeing the same incorrect behaviour again and again, and having a firm rule that expressly forbids the easiest fix to that behaviour?
I've always added it to the project's gitignore because I want to make sure nobody else adds those to the project, either, out of ignorance. I'm mainly doing it out of kindness to them, because I am definitely removing them from git again and it's going to cause them some pain.
In the future, I think I might just be less nice about it. I dunno.