Slightly adjust internal gix_path::env::git-related organization
#1568
Conversation
This moves the `first_file_from_config_with_origin` test into the nested `exe_info` module, because like the other functions tested there, `first_file_from_config_with_origin` is a helper function for `EXE_INFO` that is separate largely to facilitate testing.
In `gix_path::env::git`.
The `gix_path::env::git::EXE_NAME` static item, while more visible than `NULL_DEVICE`, was crate-internal via `pub(super)`. So making it a `const` instead, as done here, is not a breaking nor otherwise user-facing change.
|
I agree with renaming However, I think this name runs the risk making it seem like the opposite of what it really is: Although the meaning may vary subtly across contexts, in my mind this is the configuration file whose configuration has the lowest priority, because the variables in it have the highest scope; setting those variables in any other scope takes precedence. I am not sure what the best name is, but maybe a better name could be |
This renames the crate-internal static item with the cached path of the highest scope nonempty config, treated as associated with the `git` installation, from `GIT_HIGHEST_PRIORITY_CONFIG_PATH` to `GIT_HIGHEST_SCOPE_CONFIG_PATH`. This reflects the propensity of "priority" to have the opposite of the intended meaning here, since configuration in this file stands to be superseded by configuration in any lower (i.e. any other) scope. See GitoxideLabs#1568 for context. I think this change from "PRIORITY" to "SCOPE" in the name preserves the benefits of the change from `EXE_INFO` to `GIT_HIGHEST_PRIORITY_CONFIG_PATH` (dd2d666), while making clearer what is going on and avoiding misinterpretations.
|
I have opened #1569 to propose the PRIORITY -> SCOPE naming adjustment I suggested above in #1568 (comment). |
This is a small follow-up to #1567. As suggested in #1567 (comment), it moves the
first_file_from_config_with_origintest case into the nestedexe_infomodule, and it changesNULL_DEVICEfromstatictoconst.This also changes
EXE_NAME, which providesgitorgit.exeand never holds a longer path even when one is ultimately used, fromstatictoconst. WhileEXE_NAMEis non-private, it is crate-internal viapub(super), so this change is still non-breaking and non-user-facing.In contrast, the static items
ALTERNATIVE_LOCATIONSandEXE_INFOcannot be madeconst. No change is made to them. It may make sense in the future forEXE_INFOto hold anOption<PathBuf>rather than anOption<BString>; depending in part on the future direction of changes related to #1523 and #1567 or to the question of which scopes are eligible to informGitInstallation, that may be required in the future. But nothing toward that is included here.