Global .gitignore files?

Recently, I wanted to add Mac OS finder's .DS_Store files to a project's .gitignore. A reviewer immediately objected to this: "This should be added to the user's ignore file, not the project's."

Huh! I didn't even know that existed!

"Global" .gitignore

If you have a look at git's .gitignore documentation, you'll see that there are four sources of ignore patterns that git considers:

  1. from command line flags, where applicable,
  2. from .gitignore files in project directories,
  3. .git/info/exclude in the project directory,
  4. AND, tadaah, I didn't know about that at all: from a file specified in the core.excludesFile option.

While there is not a standard place for a "global" gitignore file, you can add one to your "global" user git config. Here you can specify ignore patterns for all your git projects.

Does it make sense?

Now back to the reviewer's objection: Does it make sense to use a global gitignore file for platform-specific files such as .DS_Store.

You could argue:

  1. Total work: If everyone puts the relevant files into their global gitignore files, then we don't have to put them into project-specific gitignore files. There are more projects than developer machines, so that is a clear win.
  2. Minimal: People using Linux or Windows will not suffer from too many ignored patterns.

Wrong

Ok, not formally wrong but in my opinion irrelevant. So wrong in the typical blog post way of things ;). If you assumed that everyone has a proper global gitignore file, then you'd have to

  1. Be annoyed about .DS_Store files occasionally sneaking into your merge requests,
  2. Educate people about its existence, and
  3. Maybe argue about the best way.

Instead, if there is no danger that your project will ever want to check in .DS_Store files, you can just add one or two additional patterns to the project .gitignore file and be done with it.

Simplify your life!

I am guilty with creating many long/messy .gitignore files, adding stuff to them whenever opportune. I never regretted that. But I WAS occasionally annoyed missing .gitignore patterns.

I never struggled from too many ignore patterns. They always just work fine.

Conclusion

We spend a lot of effort to make it easy to onboard new developers to projects. Or at least we should, if we want collaboration. Instead of longer onboarding guides with what tools to set up, I prefer tools like nix or any other way to specify toolchain versions etc.

Why then, should we make assumptions about the setup of developer machines where we can do without?

Make your project friendly to developers of different platforms and let them include .gitignore patterns that apply to their OS, their tools, their editors.

Obviously, this is my opinion and I'd love to find out if you disagree! Maybe I have missed an important aspect? Feel free to get in touch with me with the information shared on my GitHub profile: kolloch