The new version of git - 1.8.2 is here and with it, git is better at ignoring things. The files and directories in your repository, that is.

From the 1.8.2 release notes you can see the following:

The patterns in .gitignore and .gitattributes files can have **/, as a pattern that matches 0 or more levels of subdirectory. E.g. "foo/**/bar" matches "bar" in "foo" itself or in a subdirectory of "foo".

This is great for ignoring, say lib folders within your src folder, but not ignoring lib folders elsewhere, especially, the root of your repsoitory. All the gross ways of achieving something like the above can be, well, ignore, and we can start using this.

Wait! 1.8.2 has even more in the art of ignoring thing:

"git check-ignore" command to help debugging .gitignore files has been added.

This seems neat! I have seen so many people struggle with trying to understand what is being ignored and what is not. Let’s see how this new command can help.

You can pass path(s) to the git check-ignore command and it will tell you the pattern from .gitignore or elsewhere that ends up ignoring the path(s).

Let’s try it out:

git init .
touch afile
mkdir bin
touch bin/abin.dll
echo "bin/" > .gitignore

Now if you do git check-ignore bin or git check-ignore bin/abin.dll, the command will spew back the paths, confirming that they are ignored. Of course, the git check-ignore command can go even further:

$ git check-ignore bin/a.dll --verbose
.gitignore:1:bin/   bin/a.dll

When you use the --verbose flag, it tells you the source of the ignore pattern, the line number, the pattern itself and the path being ignored because of the pattern.

While most of the times our git ignores are pretty simple like bi/ or *.dll, but for the times when things go out of hand, it makes sense to use the git check-ignore command to debug what is going on.