3 ms·

Yeah, the article's point is also that you need both: > The contents of the repo’s git ignore is for the project only files and folders. Developers can customi

Yeah, the article's point is also that you need both: > The contents of the repo’s git ignore is for the project only files and folders. Developers can customise their own global git ignore with extra exclusions they need. The two gitignores are for different purposes. The user-specific gitignore (~/.gitignore, or ~/.config/git/ignore) is tailored to the developer's specific workflow and preferred tools, so for example, a Vim user would have different rules from an Emacs or VSCode user. The project-level gitignore(s) are for build products. For example, if the project's build scripts create a "build" directory for all the build products, "build/" would probably be in the project's .gitignore. It doesn't make sense to put editor-specific stuff in the project's .gitignore because the editor or IDE a contributor chooses to use to develop the project is orthogonal to the code in the project.

nullindividual 2y ago
> It doesn't make sense to put editor-specific stuff in the project's .gitignore because the editor or IDE a contributor chooses to use to develop the project is orthogonal to the code in the project. Why not? What's the harm? There seems to be zero significant downsides to include editor or operating system-specific patterns in the project .gitignore. A long .gitignore doesn't cause performance issues. To wit, you'll ultimately have someone without a global .gitignore that will lead to PR cleanup (or worse, direct commits). The project level .gitignore prevents mistakes by all committers. This is superior to trusting a developer correctly set up their own .gitignore. I think this is getting to the level of "optimization" because it feels good rather than doing any true good.