How to tell git to ignore global config
git
Solution
Another approach, with Git 2.32 (Q2 2021), is to use the new `GIT_CONFIG_SYSTEM`:
Git 2.32 replaces `GIT_CONFIG_NOSYSTEM` mechanism to decline from reading the system-wide configuration file with `GIT_CONFIG_SYSTEM` that lets users specify from which file to read the system-wide configuration (setting it to an empty file would essentially be the same as setting NOSYSTEM), and introduce `GIT_CONFIG_GLOBAL` to override the per-user configuration in `$HOME/.gitconfig`.
See commit 482d549 (23 Apr 2021), and commit 4179b48, commit 1e06eb9, commit c62a999 (19 Apr 2021) by Patrick Steinhardt (`pks-t`). (Merged by Junio C Hamano -- `gitster` -- in commit e706aaf, 07 May 2021)
`config`: allow overriding of global and system configuration
Signed-off-by: Patrick Steinhardt
In order to have git run in a fully controlled environment without any misconfiguration, it may be desirable for users or scripts to override global- and system-level configuration files. We already have a way of doing this, which is to unset both HOME and `XDG_CONFIG_HOME` environment variables and to set `GIT_CONFIG_NOGLOBAL=true`. This is quite kludgy, and unsetting the first two variables likely has an impact on other executables spawned by such a script.
The obvious way to fix this would be to introduce `GIT_CONFIG_NOGLOBAL` as an equivalent to `GIT_CONFIG_NOSYSTEM`. But in the past, it has turned out that this design is inflexible: we cannot test system-level parsing of the git configuration in our test harness because there is no way to change its location, so all tests run with `GIT_CONFIG_NOSYSTEM` set.
Instead of doing the same mistake with `GIT_CONFIG_NOGLOBAL`, introduce two new variables `GIT_CONFIG_GLOBAL` and `GIT_CONFIG_SYSTEM`:
- If unset, git continues to use the usual locations.
- If set to a specific path, we skip reading the normal configuration files and instead take the path. By setting the path to `/dev/null`, no configuration will be loaded for the respective level.
This implements the usecase where we want to execute code in a sanitized environment without any potential misconfigurations via `/dev/null`, but is more flexible and allows for more usecases than simply adding `GIT_CONFIG_NOGLOBAL`.
`git config` now includes in its man page:
`GIT_CONFIG_GLOBAL`
`GIT_CONFIG_SYSTEM`
Take the configuration from the given files instead from global or system-level configuration.
`git` now includes in its man page:
`GIT_CONFIG_GLOBAL`
`GIT_CONFIG_SYSTEM`
Take the configuration from the given files instead from global or system-level configuration files. If `GIT_CONFIG_SYSTEM` is set, the system config file defined at build time (usually `/etc/gitconfig`) will not be read. Likewise, if `GIT_CONFIG_GLOBAL` is set, neither `$HOME/.gitconfig` nor `$XDG_CONFIG_HOME/git/config` will be read. Can be set to `/dev/null` to skip reading configuration files of the respective level.
Example, baltakatei mentions in the comments, possibly in this context:
Running `export GIT_CONFIG_GLOBAL=''; export GIT_CONFIG_SYSTEM=''` before running `make` allowed me to compile a program that expects `git log -1 --pretty=oneline somefile` to get a commit hash when I have `log.showsignature=true` in my `~/.gitconfig` file. (`git log-1 --pretty=oneline` can print more than one line depending on what's in `gitconfig` files). Context: compiling Kaldi, a speech transcription program.
Problem
The Git docs talk about the default global git config file locations (`$XDG_CONFIG_HOME/git/config` or `~/.gitconfig`), but don't offer a way to tell a git command to ignore that file. I'm looking for an environment variable, maybe called `$GIT_CONFIG_NOGLOBAL` (similar to `$GIT_CONFIG_NOSYSTEM`), or a flag to pass to git commands (for example `--ignore-global-config`). I need it because my standard git settings (especially `commit.gpgsign true`) interfere with test suites that use git. If it's not currently possible I can raise an issue on their issue tracker.