When would you use .git/info/exclude instead of .gitignore to exclude files?

Solution 1:

The advantage of .gitignore is that it can be checked into the repository itself, unlike .git/info/exclude. Another advantage is that you can have multiple .gitignore files, one inside each directory/subdirectory for directory specific ignore rules, unlike .git/info/exclude.

So, .gitignore is available across all clones of the repository. Therefore, in large teams all people are ignoring the same kind of files Example *.db, *.log. And you can have more specific ignore rules because of multiple .gitignore.

.git/info/exclude is available for individual clones only, hence what one person ignores in his clone is not available in some other person's clone. For example, if someone uses Eclipse for development it may make sense for that developer to add .build folder to .git/info/exclude because other devs may not be using Eclipse.

In general, files/ignore rules that have to be universally ignored should go in .gitignore, and otherwise files that you want to ignore only on your local clone should go into .git/info/exclude

Solution 2:

Googled : 3 ways of excluding files

1. .gitignore applies to every clone of this repository (versioned, everyone will have it),
2. .git/info/exclude only applies to your local copy of this repository (local, not shared with others),
3. ~/.gitignore applies to all the repositories on your computer (local, not shared with others).

3. actually requires to set a configuration on your computer :

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

Solution 3:

Just to offer our (real world) experience: we started using .git/info/exclude when we had to customize some config files on each development environment but still wanted the source to be maintained in the repo and available to other developers.

This way, the local files, once cloned and modified can be excluded from commits without affecting the original files in the repo but without necessarily being ignored in the repo either.