git/environment.h, branch v2.50.0

Merge branch 'ab/environment-clean-header'

2025-04-17T17:28:20Z

Code clean-up. * ab/environment-clean-header: environment.h: remove unused variables

environment.h: remove unused variables

2025-04-09T16:24:46Z

packed_git_window_size and packed_git_limit are not used anywhere in the codebase. A search found that all references were removed in d284713bae (config: make `packed_git_(limit|window_size)` non-global variables, 2024-12-03), except the ones in this file, as they were moved to struct repo_settings. Remove packed_git_window_size and packed_git_limit from environment.h. Signed-off-by: Arnav Bhate Acked-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

environment: move access to "core.bigFileThreshold" into repo settings

2025-03-10T20:16:18Z

The "core.bigFileThreshold" setting is stored in a global variable and populated via `git_default_core_config()`. This may cause issues in the case where one is handling multiple different repositories in a single process with different values for that config key, as we may or may not see the correct value in that case. Furthermore, global state blocks our path towards libification. Refactor the code so that we instead store the value in `struct repo_settings`, where the value is computed as-needed and cached. Note that this change requires us to adapt one test in t1050 that verifies that we die when parsing an invalid "core.bigFileThreshold" value. The exercised Git command doesn't use the value at all, and thus it won't hit the new code path that parses the value. This is addressed by using git-hash-object(1) instead, which does read the value. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

environment: move access to "core.sharedRepository" into repo settings

2025-02-28T21:54:11Z

Similar as with the preceding commit, we track "core.sharedRepository" via a pair of global variables. Move them into `struct repo_settings` so that we can instead track them per-repository. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

environment: move access to "core.hooksPath" into repo settings

2025-02-28T21:54:11Z

The "core.hooksPath" setting is stored in a global variable and populated via the `git_default_core_config`. This may cause issues in the case where one is handling multiple different repositories in a single process with different values for that config key, as we may or may not see the correct value in that case. Furthermore, global state blocks our path towards libification. Refactor the code so that we instead store the value in `struct repo_settings`. The value is computed as-needed and cached. The result should be functionally the same as there aren't ever any code paths where we'd execute hooks outside the context of a repository. Note that this requires us to change the passed-in repository in the `repo_git_path()` family of functions to be non-constant, as we call `adjust_git_path()` there. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

config: make `delta_base_cache_limit` a non-global variable

2024-12-03T23:21:55Z

The `delta_base_cache_limit` variable is a global config variable used by multiple subsystems. Let's make this non-global, by adding this variable independently to the subsystems where it is used. First, add the setting to the `repo_settings` struct, this provides access to the config in places where the repository is available. Use this in `packfile.c`. In `index-pack.c` we add it to the `pack_idx_option` struct and its constructor. While the repository struct is available here, it may not be set because `git index-pack` can be used without a repository. In `gc.c` add it to the `gc_config` struct and also the constructor function. The gc functions currently do not have direct access to a repository struct. These changes are made to remove the usage of `delta_base_cache_limit` as a global variable in `packfile.c`. This brings us one step closer to removing the `USE_THE_REPOSITORY_VARIABLE` definition in `packfile.c` which we complete in the next patch. Signed-off-by: Karthik Nayak Signed-off-by: Junio C Hamano

environment: stop storing "core.notesRef" globally

2024-09-12T17:15:44Z

Stop storing the "core.notesRef" config value globally. Instead, retrieve the value in `default_notes_ref()`. The code is never called in a hot loop anyway, so doing this on every invocation should be perfectly fine. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

environment: stop storing "core.warnAmbiguousRefs" globally

2024-09-12T17:15:44Z

Same as the preceding commits, storing the "core.warnAmbiguousRefs" value globally is misdesigned as this setting may be set per repository. Move the logic into the repo-settings subsystem. The usual pattern here is that users are expected to call `prepare_repo_settings()` before they access the settings themselves. This seems somewhat fragile though, as it is easy to miss and leads to somewhat ugly code patterns at the call sites. Instead, introduce a new function that encapsulates this logic for us. This also allows us to change how exactly the lazy initialization works in the future, e.g. by only partially initializing values as requested by the caller. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

environment: stop storing "core.preferSymlinkRefs" globally

2024-09-12T17:15:43Z

Same as the preceding commit, storing the "core.preferSymlinkRefs" value globally is misdesigned as this setting may be set per repository. There is only a single user of this value anyway, namely the "files" backend. So let's just remove the global variable and read the value of this setting when initializing the backend. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

environment: stop storing "core.logAllRefUpdates" globally

2024-09-12T17:15:43Z

The value of "core.logAllRefUpdates" is being stored in the global variable `log_all_ref_updates`. This design is somewhat aged nowadays, where it is entirely possible to access multiple repositories in the same process which all have different values for this setting. So using a single global variable to track it is plain wrong. Remove the global variable. Instead, we now provide a new function part of the repo-settings subsystem that parses the value for a specific repository. While that may require us to read the value multiple times, we work around this by reading it once when the ref backends are set up and caching the value there. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano