fix: Don't read "installation" config from GIT_CONFIG

When `gix-path` runs `git config -l ...` to obtain the path of a
configuration file to regard as being associated with the `git`
installation itself, it now no longer allows `GIT_CONFIG` to affect
this path.

Previously, setting `GIT_CONFIG` would treat it as the path of a
`GitInstallation` configuration file. Although it is possible that
this may have been used intentionally, it was never documented, did
not work reliably on all platforms, and carried significant
disadvantages. This is most likely a non-breaking change.

The disadvantages of treating a path in `GIT_CONFIG` as the path
to a configuration file associated with the `git` installation
were:

- For `git`, the `GIT_CONFIG` environment variable *only* affects
  `git config` commands, and not other commands that use
  configuration variables (which are most `git` commands). But when
  `gix-path` would obtain a path from `git config -l ...` that came
  from `GIT_CONFIG`, that configuration file would be used
  anywhere, and not only `gix config` commands.

- Even for `gix config`, it is not at all clear that the
  `GIT_CONFIG` environment variable ought to be honored, because
  `gix config` has a different interface from and is not meant to
  be a drop-in replacement for `git config`, and because this
  environment variable is only even supported by `git config` for
  historical reasons. (In `git config`, one should typically use
  `--file` instead.)

- The installation path is generally the path of a high-scoped
  configuration file, usually the system scope or, with Apple Git
  on macOS, the "unknown" scope even higher than that (of a file
  located under `/Library` or `/Applications`). In contrast, the
  `GIT_CONFIG` environment variable is really command scope, since
  it is an alternative way of achieving the same goal as `--file`
  when running `git config`, which `git` supports only for backward
  compatibility.

- On Windows, when `EXEPATH` is set in a way that indentifies a
  Git for Windows installation directory, which is typically the
  case in a Git Bash environment (and not otherwise), `GIT_CONFIG`
  is not used by the public `gix-path` functions that ordinarily
  get information from calling `git config -l ...`, because this
  call is not performed and instead the location of a configuration
  file associated with the installation is inferred from that
  value.

  Although this also applies to some other ways the environment
  affects the behavior of `git config -l ...`, it is much stranger
  for `GIT_CONFIG`, because whether `GIT_CONFIG` should be used
  does not intuitively seem like it should be related to what other
  sources of information are available; the semantics of
  `GIT_CONFIG` for `git` are to be ignored by most commands, but to
  always be used commands (`git config`) that do not ignore it.

- The effect on finding other files associated with the
  installation, such as a gitattributes file, may be especially
  hard to reason about for `GIT_CONFIG`. Such paths are sometimes
  inferred from the path that `gix-path` reports. In particular,
  this is how `installation_config_prefix()` works.

This change only prevents `GIT_CONFIG` from specifying an
installation config file or suppressing the search for it. This
does not affect how other `GIT_CONFIG_*` environment variables are
used.

Author: EliahKagan

gix-path/src/env/git/mod.rs

@@ -140,6 +140,7 @@ fn git_cmd(executable: PathBuf) -> Command {
     // scope. Although `GIT_CONFIG_NOSYSTEM` will suppress this as well, passing --system omits it.
     cmd.args(["config", "-lz", "--show-origin", "--name-only"])
         .current_dir(cwd)
+        .env_remove("GIT_CONFIG")
         .env_remove("GIT_DISCOVERY_ACROSS_FILESYSTEM")
         .env_remove("GIT_OBJECT_DIRECTORY")
         .env_remove("GIT_ALTERNATE_OBJECT_DIRECTORIES")