It turns out that git offers three mechanisms to specify which files to ignore. Most people know about the .gitignore files inside the working tree. But if you take a look at the gitignore documentation you’ll find out that there’s a second file to specify ignore patterns that are specific to a given user’s work-flow, but that shouldn’t be cluttering the .gitignore files inside the repo, which are normally also versioned by git and thus shared by all the developers working in the project. Patterns like these should go in the $GIT_DIR/info/exclude file, where $GIT_DIR usually refers to the .git/ directory inside your working tree.

Nobody cares what’s your favorite editor and you shouldn’t be cluttering the ignore files versioned inside the repo with the patterns of the files generated by your working environment. That way your buddies on a Mac won’t laugh at you when they notice you are stuck with Netbeans because you’re on Linux, or that you are geeky enough to use Emacs or Vim instead of the sexy TextMate.

But wait. We still have to repeat all those pesky private ignore patterns in every different project, when we should be able to tell git globally about the garbage we normally want to ignore. DRY anybody?

You’re right. That sounds very stupid. We are programmers after all. We’re supposed to be clever and lazy. So is the guy who invented all this git thing. It turns out that you can specify a global .gitignore file via git-config.

git-config --global core.excludesfile /Users/ernesto/.gitignore

The file doesn’t have to be named .gitignore and it doesn’t have to be in your home directory. The core.excludesfile configuration directive is there precisely so that you can put this global ignore file anywhere you want. Also, beware of using ~/ to specify that the file is in your home directory. The documentation says that it works and expands it to the value of the $HOME environment variable, but it doesn’t work in my Mac.

So now you can go and edit that file and put the things that bother you privately. Mine for instance is something like this.

.DS_Store
.svn
*~
*.[oa]
*.kpf
nbproject
Thumbs.db

Currently it works as a Ruby interface to Mercurial, but they are aiming high. According to their own definition, “[their] goal is to produce a piece of software that lets you forget that you’re working on git project one moment and a Mercurial project the next.” A sort of meta-interface for most modern distributed VCS’s out there, so that you can use them all with the same set of commands, or maybe even interact between different VCS’s. Although I haven’t had the time yet to truly play with it, It appears to be highly customizable.

BTW, they also mention svn and cvs as VCS’s they want to support, but I can’t see why to drain out resources into these dinosaurs. I still don’t get why people still use centralized-only VCS’s if they have the choice of distributed version control. But anyway, I wish them good luck with the project overall, and I will sure keep an eye on it for a while.