git/environment.h, 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

refs: add GIT_REFERENCE_BACKEND to specify reference backend

2026-02-25T17:40:00Z

Git allows setting a different object directory via 'GIT_OBJECT_DIRECTORY', but provides no equivalent for references. In the previous commit we extended the 'extensions.refStorage' config to also support an URI input for reference backend with location. Let's also add a new environment variable 'GIT_REFERENCE_BACKEND' that takes in the same input as the config variable. Having an environment variable allows us to modify the reference backend and location on the fly for individual Git commands. The environment variable also allows usage of alternate reference directories during 'git-clone(1)' and 'git-init(1)'. Add the config to the repository when created with the environment variable set. When initializing the repository with an alternate reference folder, create the required stubs in the repositories $GIT_DIR. The inverse, i.e. removal of the ref store doesn't clean up the stubs in the $GIT_DIR since that would render it unusable. Removal of ref store is only used when migrating between ref formats and cleanup of the $GIT_DIR doesn't make sense in such a situation. Helped-by: Jean-Noël Avila Signed-off-by: Karthik Nayak Signed-off-by: Junio C Hamano

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

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

config: warn on core.commentString=auto

2025-08-26T15:52:44Z

As support for this setting was deprecated in the last commit print a warning (or die when WITH_BREAKING_CHANGES is enabled) if it is set. Avoid bombarding the user with warnings by only printing it (a) when running commands that call "git commit" and (b) only once per command. Some scaffolding is added to repo_read_config() to allow it to detect deprecated config settings and warn about them. As both "core.commentChar" and "core.commentString" set the comment character we record which one of them is used and tailor the warning message appropriately. Note the odd combination of die_message() followed by die(NULL) is to allow the next commit to insert a call to advise() in the middle. Signed-off-by: Phillip Wood Signed-off-by: Junio C Hamano

breaking-changes: deprecate support for core.commentString=auto

2025-08-26T15:47:37Z

When "core.commentString" is set to "auto" then "git commit" will automatically select the comment character ensuring that it is not the first character on any of the lines in the commit message. This was introduced by commit 84c9dc2c5a2 (commit: allow core.commentChar=auto for character auto selection, 2014-05-17). The motivation seems to be to avoid commenting out lines from the existing message when amending a commit that was created with a message from a file. Unfortunately this feature does not work with: * commit message templates that contain comments. * prepare-commit-msg hooks that introduce comments. * "git commit --cleanup=strip --edit -F " which means that it is incompatible with - the "fixup" and "squash" commands of "git rebase -i" as the comments added by those commands are then treated as part of the commit message. - the conflict comments added to the commit message by "git cherry-pick", "git rebase" etc. as these comments are then treated as part of the commit message. It is also ignored by "git notes" when amending a note. The issues with comments coming from a template, hook or file are a consequence of the design of this feature and are therefore hard to fix. As the costs of this feature outweigh the benefits, deprecate it and remove it in Git 3.0. If someone comes up with some patches that fix all the issues in a maintainable way then I'd be happy to see this change reverted. The next commits will add a warning and some advice for users on how they can update their config settings. Signed-off-by: Phillip Wood Signed-off-by: Junio C Hamano