Comment by jasonhansel
2 days ago
More importantly, it avoids the issue where every new editor requires an addition to every repository's gitignore file (.idea, .vscode, etc).
IMO, it's best to keep things that are "your fault" (e.g. produced by your editor or OS) in your global gitignore, and only put things that are "the repository's fault" (e.g. build artifacts, test coverage reports) in the repository's gitignore file.
It can be quite useful to check in project-wide shared editor settings so that everyone in the team is using the same linter/formatter editor settings. We do that in my team for VS Code settings and extensions, even tasks.
I haven't checked if there's a way to maintain a project-scoped _personal_ `.vscode` for those idiosyncratic settings or extensions you want applied to only this project but wouldn't be appropriate to foist on everyone else. I hope there is.
> IMO, it's best to keep things that are "your fault" (e.g. produced by your editor or OS) in your global gitignore, and only put things that are "the repository's fault" (e.g. build artifacts, test coverage reports) in the repository's gitignore file.
Very well put. This should be in the git-ignore manpage.