git/config.c, branch jch

Merge branch 'jt/config-lock-timeout' into jch

2026-04-17T04:27:22Z

The code path to update the configuration file has been taught to use a short timeout to retry. * jt/config-lock-timeout: config: retry acquiring config.lock for 100ms

Merge branch 'cl/conditional-config-on-worktree-path' into jch

2026-04-17T04:27:22Z

The [includeIf "condition"] conditional inclusion facility for configuration files has learned to use the location of worktree in its condition. Comments? * cl/conditional-config-on-worktree-path: config: add "worktree" and "worktree/i" includeIf conditions config: refactor include_by_gitdir() into include_by_path()

config: add a repo_config_get_uint() helper

2026-04-10T14:58:53Z

Next commits add a 'hook.jobs' config option of type 'unsigned int', so add a helper to parse it since the API only supports int and ulong. An alternative is to make 'hook.jobs' an 'int' or parse it as an 'int' then cast it to unsigned, however it's better to use proper helpers for the type. Using 'ulong' is another option which already has helpers, but it's a bit excessive in size for just the jobs number. Signed-off-by: Adrian Ratiu Signed-off-by: Junio C Hamano

config: retry acquiring config.lock for 100ms

2026-04-03T17:37:21Z

When multiple processes write to a config file concurrently, they contend on its ".lock" file, which is acquired via open(O_EXCL) with no retry. The losers fail immediately with "could not lock config file". Two processes writing unrelated keys (say, "branch.a.remote" and "branch.b.remote") have no semantic conflict, yet one of them fails for a purely mechanical reason. This bites in practice when running `git worktree add -b` concurrently against the same repository. Each invocation makes several writes to ".git/config" to set up branch tracking, and tooling that creates worktrees in parallel sees intermittent failures. Worse, `git worktree add` does not propagate the failed config write to its exit code: the worktree is created and the command exits 0, but tracking configuration is silently dropped. The lock is held only for the duration of rewriting a small file, so retrying for 100 ms papers over any realistic contention while still failing fast if a stale lock has been left behind by a crashed process. This mirrors what we already do for individual reference locks (4ff0f01cb7 (refs: retry acquiring reference locks for 100ms, 2017-08-21)). Signed-off-by: Jörg Thalheim Signed-off-by: Junio C Hamano

config: add "worktree" and "worktree/i" includeIf conditions

2026-04-03T15:43:18Z

The includeIf mechanism already supports matching on the .git directory path (gitdir) and the currently checked out branch (onbranch). But in multi-worktree setups the .git directory of a linked worktree points into the main repository's .git/worktrees/ area, which makes gitdir patterns cumbersome when one wants to include config based on the working tree's checkout path instead. Introduce two new condition keywords: - worktree: matches the realpath of the current worktree's working directory (i.e. repo_get_work_tree()) against a glob pattern. This is the path returned by git rev-parse --show-toplevel. - worktree/i: is the case-insensitive variant. The implementation reuses the include_by_path() helper introduced in the previous commit, passing the worktree path in place of the gitdir. The condition never matches in bare repositories (where there is no worktree) or during early config reading (where no repository is available). Add documentation describing the new conditions and their supported pattern features (glob wildcards, **/ and /**, ~ expansion, ./ relative paths, and trailing-/ prefix matching). Add tests covering bare repositories, multiple worktrees, and symlinked worktree paths. Signed-off-by: Chen Linxuan Signed-off-by: Junio C Hamano

config: refactor include_by_gitdir() into include_by_path()

2026-04-03T15:43:18Z

The include_by_gitdir() function matches the realpath of a given path against a glob pattern, but its interface is tightly coupled to the gitdir condition: it takes a struct config_options *opts and extracts opts->git_dir internally. Refactor it into a more generic include_by_path() helper that takes a const char *path parameter directly, and update the gitdir and gitdir/i callers to pass opts->git_dir explicitly. No behavior change, just preparing for the addition of a new worktree condition that will reuse the same path-matching logic with a different path. Signed-off-by: Chen Linxuan Signed-off-by: Junio C Hamano

global: constify some pointers that are not written to

2026-02-06T01:52:49Z

The recent glibc 2.43 release had the following change listed in its NEWS file: For ISO C23, the functions bsearch, memchr, strchr, strpbrk, strrchr, strstr, wcschr, wcspbrk, wcsrchr, wcsstr and wmemchr that return pointers into their input arrays now have definitions as macros that return a pointer to a const-qualified type when the input argument is a pointer to a const-qualified type. When compiling with GCC 15, which defaults to -std=gnu23, this causes many warnings like this: merge-ort.c: In function ‘apply_directory_rename_modifications’: merge-ort.c:2734:36: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] 2734 | char *last_slash = strrchr(cur_path, '/'); | ^~~~~~~ This patch fixes the more obvious ones by making them const when we do not write to the returned pointer. Signed-off-by: Collin Funk Signed-off-by: Junio C Hamano

Merge branch 'rs/parse-config-expiry-simplify'

2026-01-06T07:33:53Z

Code clean-up. * rs/parse-config-expiry-simplify: config: use git_parse_int() in git_config_get_expiry_in_days()

config: use git_parse_int() in git_config_get_expiry_in_days()

2025-12-28T05:04:15Z

git_config_get_expiry_in_days() calls git_parse_signed() with the maximum value of int, which is equivalent to calling git_parse_int(). Do that instead, as its shorter and clearer. This requires demoting "days" to int to match. Promote "scale" to intmax_t in turn to arrive at the same result when multiplying them. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

Merge branch 'jc/optional-path'

2025-12-05T05:49:56Z

"git config get --path" segfaulted on an ":(optional)path" that does not exist, which has been corrected. * jc/optional-path: config: really treat missing optional path as not configured config: really pretend missing :(optional) value is not there config: mark otherwise unused function as file-scope static