git/environment.c, branch jch

Merge branch 'ob/core-attributesfile-in-repository'

2026-03-05T18:04:49Z

The core.attributesfile is intended to be set per repository, but were kept track of by a single global variable in-core, which has been corrected by moving it to per-repository data structure. * ob/core-attributesfile-in-repository: environment: move "branch.autoSetupMerge" into `struct repo_config_values` environment: stop using core.sparseCheckout globally environment: stop storing `core.attributesFile` globally

environment: move "branch.autoSetupMerge" into `struct repo_config_values`

2026-02-26T15:22:53Z

The config value `branch.autoSetupMerge` is parsed in `git_default_branch_config()` and stored in the global variable `git_branch_track`. This global variable can be overwritten by another repository when multiple Git repos run in the the same process. Move this value into `struct repo_config_values` in the_repository to retain current behaviours and move towards libifying Git. Since the variable is no longer a global variable, it has been renamed to `branch_track` in the struct `repo_config_values`. Suggested-by: Phillip Wood Mentored-by: Christian Couder Mentored-by: Usman Akinyemi Signed-off-by: Olamide Caleb Bello Signed-off-by: Junio C Hamano

environment: stop using core.sparseCheckout globally

2026-02-26T15:22:51Z

The config value `core.sparseCheckout` is parsed in `git_default_core_config()` and stored globally in `core_apply_sparse_checkout`. This could cause it to be overwritten by another repository when different Git repositories run in the same process. Move the parsed value into `struct repo_config_values` in the_repository to retain current behaviours and move towards libifying Git. Suggested-by: Phillip Wood Mentored-by: Christian Couder Mentored-by: Usman Akinyemi Signed-off-by: Olamide Caleb Bello Signed-off-by: Junio C Hamano

mailmap: drop global config variables

2026-02-20T16:13:58Z

The 'mailmap.file' and 'mailmap.blob' configurations are currently parsed and stored in the global variables 'git_mailmap_file' and 'git_mailmap_blob'. Since these values are typically only needed once when initializing a mailmap, there is no need to keep them as global state throughout the lifetime of the Git process. To reduce global state, remove these global variables and instead use 'repo_config_get_*' functions to read the configuration on demand. Signed-off-by: Burak Kaan Karaçay Signed-off-by: Junio C Hamano

Merge branch 'pc/lockfile-pid'

2026-02-17T21:30:41Z

Allow recording process ID of the process that holds the lock next to a lockfile for diagnosis. * pc/lockfile-pid: lockfile: add PID file for debugging stale locks

environment: stop storing `core.attributesFile` globally

2026-02-17T20:09:42Z

The `core.attributeFile` config value is parsed in git_default_core_config(), loaded eagerly and stored in the global variable `git_attributes_file`. Storing this value in a global variable can lead to it being overwritten by another repository when more than one Git repository run in the same Git process. Create a new struct `repo_config_values` to hold this value and other repository dependent values parsed by `git_default_config()`. This will ensure the current behaviour remains the same while also enabling the libification of Git. An accessor function 'repo_config_values()' s created to ensure that we do not access an uninitialized repository, or an instance of a different repository than the current one. Suggested-by: Phillip Wood Mentored-by: Christian Couder Mentored-by: Usman Akinyemi Helped-by: Junio C Hamano Signed-off-by: Olamide Caleb Bello Signed-off-by: Junio C Hamano

lockfile: add PID file for debugging stale locks

2026-01-22T20:15:46Z

When a lock file is held, it can be helpful to know which process owns it, especially when debugging stale locks left behind by crashed processes. Add an optional feature that creates a companion PID file alongside each lock file, containing the PID of the lock holder. For a lock file "foo.lock", the PID file is named "foo~pid.lock". The tilde character is forbidden in refnames and allowed in Windows filenames, which guarantees no collision with the refs namespace (e.g., refs "foo" and "foo~pid" cannot both exist). The file contains a single line in the format "pid " followed by a newline. The PID file is created when a lock is acquired (if enabled), and automatically cleaned up when the lock is released (via commit or rollback). The file is registered as a tempfile so it gets cleaned up by signal and atexit handlers if the process terminates abnormally. When a lock conflict occurs, the code checks for an existing PID file and, if found, uses kill(pid, 0) to determine if the process is still running. This allows providing context-aware error messages: Lock is held by process 12345. Wait for it to finish, or remove the lock file to continue. Or for a stale lock: Lock was held by process 12345, which is no longer running. Remove the stale lock file to continue. The feature is controlled via core.lockfilePid configuration (boolean). Defaults to false. When enabled, PID files are created for all lock operations. Existing PID files are always read when displaying lock errors, regardless of the core.lockfilePid setting. This ensures helpful diagnostics even when the feature was previously enabled and later disabled. Signed-off-by: Paulo Casaretto Signed-off-by: Junio C Hamano

Merge branch 'rs/tree-wo-the-repository'

2026-01-22T00:16:28Z

Remove implicit reliance on the_repository global in the APIs around tree objects and make it explicit which repository to work in. * rs/tree-wo-the-repository: cocci: remove obsolete the_repository rules cocci: convert parse_tree functions to repo_ variants tree: stop using the_repository tree: use repo_parse_tree() path-walk: use repo_parse_tree_gently() pack-bitmap-write: use repo_parse_tree() delta-islands: use repo_parse_tree() bloom: use repo_parse_tree() add-interactive: use repo_parse_tree_indirect() tree: add repo_parse_tree*() environment: move access to core.maxTreeDepth into repo settings

environment: move access to core.maxTreeDepth into repo settings

2026-01-10T02:36:16Z

The config setting core.maxTreeDepth is stored in a global variable and populated by the function git_default_core_config. This won't work if we need to access multiple repositories with different values of that setting in the same process. Store the setting in struct repo_settings instead and track it separately for each repository. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

init: do parse _all_ core.* settings early

2026-01-10T02:28:36Z

In Git for Windows, `has_symlinks` is set to 0 by default. Therefore, we need to parse the config setting `core.symlinks` to know if it has been set to `true`. In `git init`, we must do that before copying the templates because they might contain symbolic links. Even if the support for symbolic links on Windows has not made it to upstream Git yet, we really should make sure that all the `core.*` settings are parsed before proceeding, as they might very well change the behavior of `git init` in a way the user intended. This fixes https://github.com/git-for-windows/git/issues/3414 Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano