Git global ignore not working

I've created the file .gitignore_global and put it in my git install directory. When I run the command:

git config --global core.excludesfile ~/.gitignore

the rules in the ignore file do not get applied to my commits.

When I rename the file .gitignore and put it in my project root, the rules do apply.

What is wrong here?

Maybe you need to do:

git config --global core.excludesfile ~/.gitignore_global 

And to have some coffee.

Thought I would chip in on this. There is another reason why the global ignore file appears not to be working. It's something that I don't think has been covered in earlier answers. It's so blindingly obvious that - of course - it's very easy to miss.

It is, that git will only ignore new files. If the file is already being tracked by git, then of course git will not ignore it! So whatever patterns in any gitignore or exclude file do not apply.

That makes sense. Why would git want to ignore modifications to files it is already tracking? If the file is to be ignored, you must first tell git not to track it, then git ignore it as described in the manual. For info on how to untrack files, see this answer.

This all leads me to ask, is it possible to ignore changes to tracked files? Again, git delivers. This answer; Git: Ignore tracked files gives us the command (replace file with the file you want to ignore):

git update-index --assume-unchanged file

Finally, here's some additional info on debugging git ignore.

The gitignore(5) Manual Page tells us:

Patterns which a user wants Git to ignore in all situations (e.g., backup or temporary files generated by the user's editor of choice) generally go into a file specified by core.excludesfile in the user's ~/.gitconfig. Its default value is $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/ignore is used instead.

So, this is new and replaces the previous ~/.gitignore_global mentioned previously.

Next, and this is really useful, is that as of 1.8.2, we now have some excellent debugging tools. Have a look at:

Git Learns to Ignore Better - New in 1.8.2

This shows how to use the new check-ignore flag to verify that git is successfully ignoring your patterns, e.g.

git check-ignore bin/a.dll --verbose

I found that when I had defined the global core.excludesfile like this:

git config --global core.excludesfile $HOME/.config/git/ignore

it didn't work. Changing it to not use the $HOME variable, like this:

git config --global core.excludesfile ~/.config/git/ignore

it immediately started working. Hope this helps someone else.

FYI:

$ git --version
git version 1.7.10.2 (Apple Git-33)

Note: starting git1.7.12 (August 2012):

The value of:

• core.attributesfile defaults to $HOME/.config/git/attributes and
• core.excludesfile defaults to $HOME/.config/git/ignore respectively when these files exist.

So if you create a $HOME/.config/git/attributes file, you don't even have to set your core.excludesfile setting.

The file must be in your home directory. On windows, it usually means: C:\documents and settings\[user].

On linux it is: /home/[user]

I had this problem because I had initially called 'git config core.excludefiles' without --global and with a wrong value, and hence it had stored the property locally. Looks like the local property hid the global one (which had the correct value), completely ignoring it.

Also I had a funny thing with encoding of this file. Somehow my Windows 10 (with Powershell) created the file with the encoding "UTF-16 LE" and somehow Git couldn't handle this. When I change the encoding to a much more sensible value of literally anything else it worked.

Adding another thing ppl might have missed, or at least where I went wrong.

I made the mistake of not copy-pasting the command and I spelled
excludefile (wrong)
instead of
excludesfile (right)
and lost definitely half an hour or so before I reevaluated the spelling, thinking it was something else.

You don't get a warning or error for setting an option that is not a valid option. You do get a warning/error message if the syntax is invalid, which is why I wrongly assumed that a spelling mistake would be caught the same way.

Another reason a global git ignore may not be working: invisible characters in the path.

I only found out this was my problem when pasting the warning message from git-check-ignore into the address bar of Chrome, where it luckily became visible:

(It wasn't visible on the terminal. And this could have been a long rabbit hole of debugging...