I found myself in a discussion online about where and how it is
appropriate to ask git to ignore the .DS_Store file that is often
created by macOS. This led me to considering disparities in the
current state of git-config and gitignore. In particular, git-config
has system-level configuration in $(prefix)/etc/gitconfig which can be
overridden on a line by line basis by configuration at the user,
repository, or command levels. However, gitignore does not have an
equivalent system-level layer. You can set core.excludesfile in the
system-level config file, but the user can only override that whole
file by changing that config option, they have no way to override
single exclude entries or even just add to the list for themselves at
the user ("global") level.
I think that a system-level ignore/exclude file would be the ideal
place for the git package on a particular OS to put OS-specific rules
like the following examples, if they wanted to do so, or for a
sysadmin or root user to do the same to cover all local accounts by
default if their OS package opted to not provide any exclude rules.
https://www.toptal.com/developers/gitignore/api/macos
https://www.toptal.com/developers/gitignore/api/windows
https://www.toptal.com/developers/gitignore/api/linux
Was the decision to not allow or implement such a file intentional, or
is it just an emergent property of the way the config system works and
how core.excludesFile was implemented? Would an implementation of a
new feature supporting this sort of thing be worth discussing?
