You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is in addition to testing it with suppressed system config,
which was already being done.
The `exe_info_never_from_local_scope*` tests are now back to the
approach they originally used, setting `GIT_CONFIG_SYSTEM` rather
than `GIT_CONFIG_NOSYSTEM`, and new tests (or, rather, the previous
ones, renamed) set `GIT_CONFIG_NOSYSTEM`.
The reason setting `GIT_CONFIG_SYSTEM` to paths like `/dev/null`
had been replaced by setting `GIT_CONFIG_NOSYSTEM` to `1` was to
make the tests work on macOS, where it is harder for an end-to-end
test to allow a system-scope configuration to be used but arrange
for it to be empty. This is harder on macOS because of the
"unknown" scope of configuration variables from a file belonging to
the installation, often in `/Library`, which is higher than the
system scope and can be suppressed via `GIT_CONFIG_NOSYSTEM`, but
which is not suppressed by setting `GIT_CONFIG_SYSTEM` to an empty
file.
The tests, brought back here, that set `GIT_CONFIG_SYSTEM` while
leaving `GIT_CONFIG_NOSYSTEM` unset, are thus skipped on macOS.
In part to allow the important functionality in play to be *mostly*
tested even on macOS, and in part because it is an important case
unto itself, this also preserves (renamed) tests that set
`GIT_CONFIG_NOSYSTEM`.
The reason to restore testing of the `GIT_CONFIG_SYSTEM` approach
is threefold:
- It is not obvious by reading the tests themselves that setting
`GIT_CONFIG_NOSYSTEM` covers cases where system scope config is
allowed but happens to provide no configuration variables.
- Although the implementation does not currently special-case
`GIT_CONFIG_NOSYSTEM` as a shortcut to elide the `git config -l`
subprocess invocation, this may be done in the future.
(I believe the main reason it is not done now is that we
currently allow global scope configuration to be treated as
belonging to the installation if no higher scope config is
available, and it is not obvious that this behavior will be
preserved.)
- Even if we get configuration we consider to be associated with
the `git` installation that does not come from the system scope,
suppressing the system scope with `GIT_CONFIG_NOSYSTEM` often
causes it not to be used. That environment variable is checked in
`gix_config::types::Source::storage_location()`, suppressing both
the `GitInstallation` and `System` cases.
Therefore, while local scope configuration leaking through would
carry some risk even when `GIT_CONFIG_NOSYSTEM` is turned on, the
significance of this is unclear, and it is not the main concern.
What most needs to be avoided is misattribuitng local scope
configuration as being associated with the `git` installation
when configuration associated with the `git` installation is
actually intended to be used.
So there should be test cases that cover that, so it is clear
that it is covered, and so it is clear from reading the test
suite that these tests really are related to a realistic problem.
The assertion messages are edited to distinguish between system
scope configuration being suppressed versus being empty (no vars).
0 commit comments