My one nit is that I take the stance that .gitignore is only for ignoring things that are "of the nature" of the project. A developer's personal tooling prefere

My one nit is that I take the stance that .gitignore is only for ignoring things that are "of the nature" of the project. A developer's personal tooling preference that might not be shared by others is not "of the nature of the project" — the project itself doesn't cause a developer to have an affinity for a particular tool; these belong in an exclude file, usually the user's global excludes file[1]. .DS_Store is an example of this: this is a file caused by the tools you're using to develop with, which are likely particular to you. My system does not generate these files. For the same reason, I wouldn't include vim swap files[2]. A ".pyc" ignore in a Python project, or a .o ignore in a C project, however, is correct, because the nature (in this case, the language in use) of the project causes* that ignore to be needed. Ask yourself who needs the file ignored: The project (.gitignore), or you (exclude)? The big benefit is that you need only exclude (or ignore) the file once: .DS_Store is likely not only invalid in one repo, but in all repos. So exclude it globally. Also, the rest of us aren't wondering "what's a .DS_Store?" `man gitignore` has a decent passage about when to use which. [1]: See `man gitignore`, and `man git-config`'s `core.excludesFile`. [2]: ".⋆.sw⋆", which is all too often ".⋆.swp" or "⋆.swp" (note: unicode magic here to avoid special meaning of "⋆"…; also, HN strips out U+2736-7's?)