I think that there are situations where ignoring the .gitignore is very useful. For instance, when you have multiple teams or a large team working on the same codebase. In that case, you need to have certain conventions, one of those convention is regarding what is ignored at the git repo. It is usually about ignoring files and directories created by IDE or OS, some generated logs, etc.
However, there is a force which is tending to introduce non-conventional changes to .gitignore
file. The .gitignore
file can be further changed by irresponsible person, by mistake, by a tool that is used, or in some other case.
To have a counter force to this, we can do as followed:
.gitignore
file is "sealed" in this way.The "sealed" .gitignore
file can be changed, just locally, without propagating that changers to other members of team(s). However, if a change is widely agreed throughout the whole team(s) than it is possible to "unseal" it, change it and than "seal" it again. That can't be done by mistake, only intentionally.
Sadly, you cannot be 100% protected from the stupidity, but this way you have done everything you can to prevent stupid things to happen.
If you have relatively small team with very good professionals, than this wouldn't be important, but even those guys would appreciate to have one thing less to worry about.
Using .git/info/exclude
is cool when you cannot do anything about infrastructure settings, just covering your own a** not to make a mistake.
From a standing point of what is right and what is wrong I am voting for having .gitignore entry inside .gitignore
file, giving everybody the freedom to do locally whatever they want, but not invading others.