Volume XXII, number 280Wednesday, October 7, 2026Latest message 57 minutes ago

The Git List

News and archive of git@vger.kernel.org, since April 2005

v3, 2 partsconfig: refactor include_by_gitdir() into include_by_path()

11 messages between Apr 3, 2026 and May 13, 2026, from Chen Linxuan via B4 Relay, Junio C Hamano, Patrick Steinhardt, Phillip Wood, Chen Linxuan.

Plain Markdown or JSON for tools and agents. Diffs are folded; open one to read it.

Chen Linxuan via B4 RelayApr 3, 2026, 07:02 UTC in reply to Chen Linxuan via B4 Relay on lore
From: Chen Linxuan <me@black-desk.cn>

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 <me@black-desk.cn>
---
 config.c | 19 ++++++++-----------
 1 file changed, 8 insertions(+), 11 deletions(-)
Show changes to config.c +8 −11
diff --git a/config.c b/config.c
index 156f2a24fa00..7d5dae0e8450 100644
--- a/config.c
+++ b/config.c
@@ -235,23 +235,20 @@ static int prepare_include_condition_pattern(const struct key_value_info *kvi,
 	return 0;
 }
 
-static int include_by_gitdir(const struct key_value_info *kvi,
-			     const struct config_options *opts,
-			     const char *cond, size_t cond_len, int icase)
+static int include_by_path(const struct key_value_info *kvi,
+			   const char *path,
+			   const char *cond, size_t cond_len, int icase)
 {
 	struct strbuf text = STRBUF_INIT;
 	struct strbuf pattern = STRBUF_INIT;
 	size_t prefix;
 	int ret = 0;
-	const char *git_dir;
 	int already_tried_absolute = 0;
 
-	if (opts->git_dir)
-		git_dir = opts->git_dir;
-	else
+	if (!path)
 		goto done;
 
-	strbuf_realpath(&text, git_dir, 1);
+	strbuf_realpath(&text, path, 1);
 	strbuf_add(&pattern, cond, cond_len);
 	ret = prepare_include_condition_pattern(kvi, &pattern, &prefix);
 	if (ret < 0)
@@ -284,7 +281,7 @@ static int include_by_gitdir(const struct key_value_info *kvi,
 		 * which'll do the right thing
 		 */
 		strbuf_reset(&text);
-		strbuf_add_absolute_path(&text, git_dir);
+		strbuf_add_absolute_path(&text, path);
 		already_tried_absolute = 1;
 		goto again;
 	}
@@ -400,9 +397,9 @@ static int include_condition_is_true(const struct key_value_info *kvi,
 	const struct config_options *opts = inc->opts;
 
 	if (skip_prefix_mem(cond, cond_len, "gitdir:", &cond, &cond_len))
-		return include_by_gitdir(kvi, opts, cond, cond_len, 0);
+		return include_by_path(kvi, opts->git_dir, cond, cond_len, 0);
 	else if (skip_prefix_mem(cond, cond_len, "gitdir/i:", &cond, &cond_len))
-		return include_by_gitdir(kvi, opts, cond, cond_len, 1);
+		return include_by_path(kvi, opts->git_dir, cond, cond_len, 1);
 	else if (skip_prefix_mem(cond, cond_len, "onbranch:", &cond, &cond_len))
 		return include_by_branch(inc, cond, cond_len);
 	else if (skip_prefix_mem(cond, cond_len, "hasconfig:remote.*.url:", &cond,
-- 
2.53.0
Chen Linxuan via B4 RelayApr 3, 2026, 07:02 UTC on lore

[PATCH v3 0/2] includeIf: add "worktree" condition for matching working tree path

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:<pattern>` matches the realpath of the current worktree's
    working directory against a glob pattern.
  - `worktree/i:<pattern>` is the case-insensitive variant.

Supported pattern features: glob wildcards, `**/` and `/**`, `~` expansion, `./` relative paths, and trailing-`/` prefix matching. The condition never matches in a bare repository.

Signed-off-by: Chen Linxuan <me@black-desk.cn>
---
Changes in v3:
- Apply Junio's suggestion.
- Link to v2: https://lore.kernel.org/r/20260402-includeif-worktree-v2-0-36e339b898d7@black-desk.cn
Changes in v2:
- Add missing signed-off-by lines.
- Link to v1: https://lore.kernel.org/r/20260401-includeif-worktree-v1-0-906db69f2c79@black-desk.cn
---
Chen Linxuan (2):
      config: refactor include_by_gitdir() into include_by_path()
      config: add "worktree" and "worktree/i" includeIf conditions
 Documentation/config.adoc | 50 +++++++++++++++++++++++++++++++++++
 config.c                  | 25 ++++++++++--------
 t/t1305-config-include.sh | 66 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 130 insertions(+), 11 deletions(-)
---
base-commit: 270e10ad6dda3379ea0da7efd11e4fbf2cd7a325
change-id: 20260401-includeif-worktree-fcb64950dfba
Best regards,
-- 
Chen Linxuan <me@black-desk.cn>
Chen Linxuan via B4 RelayApr 3, 2026, 07:02 UTC in reply to Chen Linxuan via B4 Relay on lore

[PATCH v3 2/2] config: add "worktree" and "worktree/i" includeIf conditions

From: Chen Linxuan <me@black-desk.cn>

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:<pattern> 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:<pattern> 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 <me@black-desk.cn>
---
 Documentation/config.adoc | 50 +++++++++++++++++++++++++++++++++++
 config.c                  |  6 +++++
 t/t1305-config-include.sh | 66 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 122 insertions(+)
Show changes to 3 files +122 −0

Documentation/config.adoc, config.c, t/t1305-config-include.sh

diff --git a/Documentation/config.adoc b/Documentation/config.adoc
index 62eebe7c5450..a4f3ec905098 100644
--- a/Documentation/config.adoc
+++ b/Documentation/config.adoc
@@ -146,6 +146,48 @@ refer to linkgit:gitignore[5] for details. For convenience:
 	This is the same as `gitdir` except that matching is done
 	case-insensitively (e.g. on case-insensitive file systems)
 
+`worktree`::
+	The data that follows the keyword `worktree` and a colon is used as a
+	glob pattern. If the working directory of the current worktree matches
+	the pattern, the include condition is met.
++
+The worktree location is the path where files are checked out (as returned
+by `git rev-parse --show-toplevel`). This is different from `gitdir`, which
+matches the `.git` directory path. In a linked worktree, the worktree path
+is the directory where that worktree's files are located, not the main
+repository's `.git` directory.
++
+The pattern can contain standard globbing wildcards and two additional
+ones, `**/` and `/**`, that can match multiple path components. Please
+refer to linkgit:gitignore[5] for details. For convenience:
+
+ * If the pattern starts with `~/`, `~` will be substituted with the
+   content of the environment variable `HOME`.
+
+ * If the pattern starts with `./`, it is replaced with the directory
+   containing the current config file.
+
+ * If the pattern does not start with either `~/`, `./` or `/`, `**/`
+   will be automatically prepended. For example, the pattern `foo/bar`
+   becomes `**/foo/bar` and would match `/any/path/to/foo/bar`.
+
+ * If the pattern ends with `/`, `**` will be automatically added. For
+   example, the pattern `foo/` becomes `foo/**`. In other words, it
+   matches "foo" and everything inside, recursively.
++
+This condition will never match in a bare repository (which has no worktree).
++
+This is useful when you need to use different `user.name`, `user.email`, or
+GPG keys in different worktrees of the same repository. While
+`extensions.worktreeConfig` also allows per-worktree configuration, it
+requires changes inside each repository. This condition can be set in the
+user's global configuration file (e.g. `~/.config/git/config`) and applies
+to multiple repositories at once.
+
+`worktree/i`::
+	This is the same as `worktree` except that matching is done
+	case-insensitively (e.g. on case-insensitive file systems)
+
 `onbranch`::
 	The data that follows the keyword `onbranch` and a colon is taken to be a
 	pattern with standard globbing wildcards and two additional
@@ -244,6 +286,14 @@ Example
 [includeIf "gitdir:~/to/group/"]
 	path = /path/to/foo.inc
 
+; include if the worktree is at /path/to/project-build
+[includeIf "worktree:/path/to/project-build"]
+	path = build-config.inc
+
+; include for all worktrees inside /path/to/group
+[includeIf "worktree:/path/to/group/"]
+	path = group-config.inc
+
 ; relative paths are always relative to the including
 ; file (if the condition is true); their location is not
 ; affected by the condition
diff --git a/config.c b/config.c
index 7d5dae0e8450..6d0c2d0725e4 100644
--- a/config.c
+++ b/config.c
@@ -400,6 +400,12 @@ static int include_condition_is_true(const struct key_value_info *kvi,
 		return include_by_path(kvi, opts->git_dir, cond, cond_len, 0);
 	else if (skip_prefix_mem(cond, cond_len, "gitdir/i:", &cond, &cond_len))
 		return include_by_path(kvi, opts->git_dir, cond, cond_len, 1);
+	else if (skip_prefix_mem(cond, cond_len, "worktree:", &cond, &cond_len))
+		return include_by_path(kvi, inc->repo ? repo_get_work_tree(inc->repo) : NULL,
+				       cond, cond_len, 0);
+	else if (skip_prefix_mem(cond, cond_len, "worktree/i:", &cond, &cond_len))
+		return include_by_path(kvi, inc->repo ? repo_get_work_tree(inc->repo) : NULL,
+				       cond, cond_len, 1);
 	else if (skip_prefix_mem(cond, cond_len, "onbranch:", &cond, &cond_len))
 		return include_by_branch(inc, cond, cond_len);
 	else if (skip_prefix_mem(cond, cond_len, "hasconfig:remote.*.url:", &cond,
diff --git a/t/t1305-config-include.sh b/t/t1305-config-include.sh
index 6e51f892f320..8a5ba4b884d3 100755
--- a/t/t1305-config-include.sh
+++ b/t/t1305-config-include.sh
@@ -396,4 +396,70 @@ test_expect_success 'onbranch without repository but explicit nonexistent Git di
 	test_must_fail nongit git --git-dir=nonexistent config get foo.bar
 '
 
+# worktree: conditional include tests
+
+test_expect_success 'conditional include, worktree bare repo' '
+	git init --bare wt-bare &&
+	(
+		cd wt-bare &&
+		echo "[includeIf \"worktree:/\"]path=bar-bare" >>config &&
+		echo "[test]wtbare=1" >bar-bare &&
+		test_must_fail git config test.wtbare
+	)
+'
+
+test_expect_success 'conditional include, worktree multiple worktrees' '
+	git init wt-multi &&
+	(
+		cd wt-multi &&
+		test_commit initial &&
+		git worktree add -b linked-branch ../wt-linked HEAD &&
+		git worktree add -b prefix-branch ../wt-prefix/linked HEAD
+	) &&
+	wt_main="$(cd wt-multi && pwd)" &&
+	wt_linked="$(cd wt-linked && pwd)" &&
+	wt_prefix_parent="$(cd wt-prefix && pwd)" &&
+	cat >>wt-multi/.git/config <<-EOF &&
+	[includeIf "worktree:$wt_main"]
+		path = main-config
+	[includeIf "worktree:$wt_linked"]
+		path = linked-config
+	[includeIf "worktree:$wt_prefix_parent/"]
+		path = prefix-config
+	EOF
+	echo "[test]mainvar=main" >wt-multi/.git/main-config &&
+	echo "[test]linkedvar=linked" >wt-multi/.git/linked-config &&
+	echo "[test]prefixvar=prefix" >wt-multi/.git/prefix-config &&
+	echo main >expect &&
+	git -C wt-multi config test.mainvar >actual &&
+	test_cmp expect actual &&
+	test_must_fail git -C wt-multi config test.linkedvar &&
+	test_must_fail git -C wt-multi config test.prefixvar &&
+	echo linked >expect &&
+	git -C wt-linked config test.linkedvar >actual &&
+	test_cmp expect actual &&
+	test_must_fail git -C wt-linked config test.mainvar &&
+	test_must_fail git -C wt-linked config test.prefixvar &&
+	echo prefix >expect &&
+	git -C wt-prefix/linked config test.prefixvar >actual &&
+	test_cmp expect actual &&
+	test_must_fail git -C wt-prefix/linked config test.mainvar &&
+	test_must_fail git -C wt-prefix/linked config test.linkedvar
+'
+
+test_expect_success SYMLINKS 'conditional include, worktree resolves symlinks' '
+	mkdir real-wt &&
+	ln -s real-wt link-wt &&
+	git init link-wt/repo &&
+	(
+		cd link-wt/repo &&
+		# repo->worktree resolves symlinks, so use real path in pattern
+		echo "[includeIf \"worktree:**/real-wt/repo\"]path=bar-link" >>.git/config &&
+		echo "[test]wtlink=2" >.git/bar-link &&
+		echo 2 >expect &&
+		git config test.wtlink >actual &&
+		test_cmp expect actual
+	)
+'
+
 test_done
-- 
2.53.0
Junio C HamanoMay 12, 2026, 06:41 UTC in reply to Chen Linxuan via B4 Relay on lore

Re: [PATCH v3 0/2] includeIf: add "worktree" condition for matching working tree path

Chen Linxuan via B4 Relay <devnull+me.black-desk.cn@kernel.org> writes:

Show 27 quoted lines
> 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:<pattern>` matches the realpath of the current worktree's
>     working directory against a glob pattern.
>   - `worktree/i:<pattern>` is the case-insensitive variant.
>
> Supported pattern features: glob wildcards, `**/` and `/**`, `~`
> expansion, `./` relative paths, and trailing-`/` prefix matching.
> The condition never matches in a bare repository.
>
> Signed-off-by: Chen Linxuan <me@black-desk.cn>
> ---
> Changes in v3:
> - Apply Junio's suggestion.
> - Link to v2: https://lore.kernel.org/r/20260402-includeif-worktree-v2-0-36e339b898d7@black-desk.cn
>
> Changes in v2:
>
> - Add missing signed-off-by lines.
> - Link to v1: https://lore.kernel.org/r/20260401-includeif-worktree-v1-0-906db69f2c79@black-desk.cn

Can we have a volunteer (or two) to review these patches? The feature sounds like a worthwhile thing to have, and the code on the surface looks OK-ish to me, but I am not fully back up to speed and can use an extra set of eyeballs.

Thanks.
Show 15 quoted lines
>
> ---
> Chen Linxuan (2):
>       config: refactor include_by_gitdir() into include_by_path()
>       config: add "worktree" and "worktree/i" includeIf conditions
>
>  Documentation/config.adoc | 50 +++++++++++++++++++++++++++++++++++
>  config.c                  | 25 ++++++++++--------
>  t/t1305-config-include.sh | 66 +++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 130 insertions(+), 11 deletions(-)
> ---
> base-commit: 270e10ad6dda3379ea0da7efd11e4fbf2cd7a325
> change-id: 20260401-includeif-worktree-fcb64950dfba
>
> Best regards,
Patrick SteinhardtMay 12, 2026, 07:13 UTC in reply to Chen Linxuan via B4 Relay on lore

Re: [PATCH v3 1/2] config: refactor include_by_gitdir() into include_by_path()

On Fri, Apr 03, 2026 at 03:02:28PM +0800, Chen Linxuan via B4 Relay wrote:
Show 12 quoted lines
> From: Chen Linxuan <me@black-desk.cn>
> 
> 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.
Good preparatory step.
Patrick
Patrick SteinhardtMay 12, 2026, 07:14 UTC in reply to Chen Linxuan via B4 Relay on lore

Re: [PATCH v3 2/2] config: add "worktree" and "worktree/i" includeIf conditions

On Fri, Apr 03, 2026 at 03:02:29PM +0800, Chen Linxuan via B4 Relay wrote:
Show 17 quoted lines
> From: Chen Linxuan <me@black-desk.cn>
> 
> 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:<pattern> 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:<pattern> is the case-insensitive variant.
Seems sensible.
Show 5 quoted lines
> 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).

Right. This is because `repo_get_work_tree()` would return a NULL pointer in these cases, and `include_by_path()` exits early in that case.

Show 36 quoted lines
> diff --git a/Documentation/config.adoc b/Documentation/config.adoc
> index 62eebe7c5450..a4f3ec905098 100644
> --- a/Documentation/config.adoc
> +++ b/Documentation/config.adoc
> @@ -146,6 +146,48 @@ refer to linkgit:gitignore[5] for details. For convenience:
>  	This is the same as `gitdir` except that matching is done
>  	case-insensitively (e.g. on case-insensitive file systems)
>  
> +`worktree`::
> +	The data that follows the keyword `worktree` and a colon is used as a
> +	glob pattern. If the working directory of the current worktree matches
> +	the pattern, the include condition is met.
> ++
> +The worktree location is the path where files are checked out (as returned
> +by `git rev-parse --show-toplevel`). This is different from `gitdir`, which
> +matches the `.git` directory path. In a linked worktree, the worktree path
> +is the directory where that worktree's files are located, not the main
> +repository's `.git` directory.
> ++
> +The pattern can contain standard globbing wildcards and two additional
> +ones, `**/` and `/**`, that can match multiple path components. Please
> +refer to linkgit:gitignore[5] for details. For convenience:
> +
> + * If the pattern starts with `~/`, `~` will be substituted with the
> +   content of the environment variable `HOME`.
> +
> + * If the pattern starts with `./`, it is replaced with the directory
> +   containing the current config file.
> +
> + * If the pattern does not start with either `~/`, `./` or `/`, `**/`
> +   will be automatically prepended. For example, the pattern `foo/bar`
> +   becomes `**/foo/bar` and would match `/any/path/to/foo/bar`.
> +
> + * If the pattern ends with `/`, `**` will be automatically added. For
> +   example, the pattern `foo/` becomes `foo/**`. In other words, it
> +   matches "foo" and everything inside, recursively.

This whole listing here is the exact same as we have for the `gitdir` condition. Can we maybe deduplicate these into a common section?

Show 17 quoted lines
> diff --git a/config.c b/config.c
> index 7d5dae0e8450..6d0c2d0725e4 100644
> --- a/config.c
> +++ b/config.c
> @@ -400,6 +400,12 @@ static int include_condition_is_true(const struct key_value_info *kvi,
>  		return include_by_path(kvi, opts->git_dir, cond, cond_len, 0);
>  	else if (skip_prefix_mem(cond, cond_len, "gitdir/i:", &cond, &cond_len))
>  		return include_by_path(kvi, opts->git_dir, cond, cond_len, 1);
> +	else if (skip_prefix_mem(cond, cond_len, "worktree:", &cond, &cond_len))
> +		return include_by_path(kvi, inc->repo ? repo_get_work_tree(inc->repo) : NULL,
> +				       cond, cond_len, 0);
> +	else if (skip_prefix_mem(cond, cond_len, "worktree/i:", &cond, &cond_len))
> +		return include_by_path(kvi, inc->repo ? repo_get_work_tree(inc->repo) : NULL,
> +				       cond, cond_len, 1);
>  	else if (skip_prefix_mem(cond, cond_len, "onbranch:", &cond, &cond_len))
>  		return include_by_branch(inc, cond, cond_len);
>  	else if (skip_prefix_mem(cond, cond_len, "hasconfig:remote.*.url:", &cond,

I feel like this is something that we might eventually want to convert to be table-driven. But I think that doesn't have to happen as part of this patch series.

> diff --git a/t/t1305-config-include.sh b/t/t1305-config-include.sh
> index 6e51f892f320..8a5ba4b884d3 100755
> --- a/t/t1305-config-include.sh
> +++ b/t/t1305-config-include.sh

Just because it was explicitly mentioned: we might also want to have a test that verifies this works with early-config parsing. We already have a similar test for "gitdir:" in "conditional include, early config reading".

And should we also have a "nongit" branch where we verify outside a repository?

Other than that this series looks good to me, thanks!
Patrick
Phillip WoodMay 12, 2026, 15:07 UTC in reply to Patrick Steinhardt on lore

Re: [PATCH v3 2/2] config: add "worktree" and "worktree/i" includeIf conditions

On 12/05/2026 08:14, Patrick Steinhardt wrote:
Show 20 quoted lines
> On Fri, Apr 03, 2026 at 03:02:29PM +0800, Chen Linxuan via B4 Relay wrote:
>> From: Chen Linxuan <me@black-desk.cn>
>>
>> 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:<pattern> 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:<pattern> is the case-insensitive variant.
> 
> Seems sensible.

We already support per-worktree config settings via extensions.worktreeConfig, so it would be helpful to explain why it is more convenient to set the config based on the worktree's path, rather than just running "git config --worktree" inside the worktree. Do you have multiple repositories with worktrees checked out under a common prefix that you want to share the same config setting?

Thanks
Phillip
Show 89 quoted lines
>> 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).
> 
> Right. This is because `repo_get_work_tree()` would return a NULL
> pointer in these cases, and `include_by_path()` exits early in that
> case.
> 
>> diff --git a/Documentation/config.adoc b/Documentation/config.adoc
>> index 62eebe7c5450..a4f3ec905098 100644
>> --- a/Documentation/config.adoc
>> +++ b/Documentation/config.adoc
>> @@ -146,6 +146,48 @@ refer to linkgit:gitignore[5] for details. For convenience:
>>   	This is the same as `gitdir` except that matching is done
>>   	case-insensitively (e.g. on case-insensitive file systems)
>>   
>> +`worktree`::
>> +	The data that follows the keyword `worktree` and a colon is used as a
>> +	glob pattern. If the working directory of the current worktree matches
>> +	the pattern, the include condition is met.
>> ++
>> +The worktree location is the path where files are checked out (as returned
>> +by `git rev-parse --show-toplevel`). This is different from `gitdir`, which
>> +matches the `.git` directory path. In a linked worktree, the worktree path
>> +is the directory where that worktree's files are located, not the main
>> +repository's `.git` directory.
>> ++
>> +The pattern can contain standard globbing wildcards and two additional
>> +ones, `**/` and `/**`, that can match multiple path components. Please
>> +refer to linkgit:gitignore[5] for details. For convenience:
>> +
>> + * If the pattern starts with `~/`, `~` will be substituted with the
>> +   content of the environment variable `HOME`.
>> +
>> + * If the pattern starts with `./`, it is replaced with the directory
>> +   containing the current config file.
>> +
>> + * If the pattern does not start with either `~/`, `./` or `/`, `**/`
>> +   will be automatically prepended. For example, the pattern `foo/bar`
>> +   becomes `**/foo/bar` and would match `/any/path/to/foo/bar`.
>> +
>> + * If the pattern ends with `/`, `**` will be automatically added. For
>> +   example, the pattern `foo/` becomes `foo/**`. In other words, it
>> +   matches "foo" and everything inside, recursively.
> 
> This whole listing here is the exact same as we have for the `gitdir`
> condition. Can we maybe deduplicate these into a common section?
> 
>> diff --git a/config.c b/config.c
>> index 7d5dae0e8450..6d0c2d0725e4 100644
>> --- a/config.c
>> +++ b/config.c
>> @@ -400,6 +400,12 @@ static int include_condition_is_true(const struct key_value_info *kvi,
>>   		return include_by_path(kvi, opts->git_dir, cond, cond_len, 0);
>>   	else if (skip_prefix_mem(cond, cond_len, "gitdir/i:", &cond, &cond_len))
>>   		return include_by_path(kvi, opts->git_dir, cond, cond_len, 1);
>> +	else if (skip_prefix_mem(cond, cond_len, "worktree:", &cond, &cond_len))
>> +		return include_by_path(kvi, inc->repo ? repo_get_work_tree(inc->repo) : NULL,
>> +				       cond, cond_len, 0);
>> +	else if (skip_prefix_mem(cond, cond_len, "worktree/i:", &cond, &cond_len))
>> +		return include_by_path(kvi, inc->repo ? repo_get_work_tree(inc->repo) : NULL,
>> +				       cond, cond_len, 1);
>>   	else if (skip_prefix_mem(cond, cond_len, "onbranch:", &cond, &cond_len))
>>   		return include_by_branch(inc, cond, cond_len);
>>   	else if (skip_prefix_mem(cond, cond_len, "hasconfig:remote.*.url:", &cond,
> 
> I feel like this is something that we might eventually want to convert
> to be table-driven. But I think that doesn't have to happen as part of
> this patch series.
> 
>> diff --git a/t/t1305-config-include.sh b/t/t1305-config-include.sh
>> index 6e51f892f320..8a5ba4b884d3 100755
>> --- a/t/t1305-config-include.sh
>> +++ b/t/t1305-config-include.sh
> 
> Just because it was explicitly mentioned: we might also want to have a
> test that verifies this works with early-config parsing. We already have
> a similar test for "gitdir:" in "conditional include, early config
> reading".
> 
> And should we also have a "nongit" branch where we verify outside a
> repository?
> 
> Other than that this series looks good to me, thanks!
> 
> Patrick
> 
Junio C HamanoMay 12, 2026, 16:09 UTC in reply to Phillip Wood on lore

Re: [PATCH v3 2/2] config: add "worktree" and "worktree/i" includeIf conditions

Phillip Wood <phillip.wood123@gmail.com> writes:
Show 19 quoted lines
> On 12/05/2026 08:14, Patrick Steinhardt wrote:
> ...
>>> Introduce two new condition keywords:
>>>
>>>    - worktree:<pattern> 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:<pattern> is the case-insensitive variant.
>> 
>> Seems sensible.
>
> We already support per-worktree config settings via 
> extensions.worktreeConfig, so it would be helpful to explain why it is 
> more convenient to set the config based on the worktree's path, rather 
> than just running "git config --worktree" inside the worktree. Do you 
> have multiple repositories with worktrees checked out under a common 
> prefix that you want to share the same config setting?

Excellent point. The documentation for the new feature may have to be strengthened to suggest which one of the two approaches is more appropriate with what use cases.

Thanks.
Chen LinxuanMay 13, 2026, 02:47 UTC in reply to Patrick Steinhardt on lore

Re: [PATCH v3 2/2] config: add "worktree" and "worktree/i" includeIf conditions

On Tue, 12 May 2026 09:14:03 +0200, Patrick Steinhardt wrote:
Show 16 quoted lines
> On Fri, Apr 03, 2026 at 03:02:29PM +0800, Chen Linxuan via B4 Relay wrote:
> > ...
> > 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).
> 
> Right. This is because `repo_get_work_tree()` would return a NULL
> pointer in these cases, and `include_by_path()` exits early in that
> case.
> 
> ...
> 
> This whole listing here is the exact same as we have for the `gitdir`
> condition. Can we maybe deduplicate these into a common section?
Sure, will be updated in V4.
Show 6 quoted lines
> ...
>
> Just because it was explicitly mentioned: we might also want to have a
> test that verifies this works with early-config parsing. We already have
> a similar test for "gitdir:" in "conditional include, early config
> reading".

As I wrote in the commit message, this is not going to work with early-config parsing. I am working on the fix. But I am not quite sure that this is a must-fix issue or not.

> And should we also have a "nongit" branch where we verify outside a
> repository?
Sure, will be added in V4.
Chen Linxuan
Chen LinxuanMay 13, 2026, 02:55 UTC in reply to Junio C Hamano on lore

Re: [PATCH v3 2/2] config: add "worktree" and "worktree/i" includeIf conditions

On Wed, May 13, 2026 at 12:09 AM Junio C Hamano <gitster@pobox.com> wrote:
Show 22 quoted lines
>
> Phillip Wood <phillip.wood123@gmail.com> writes:
>
> > On 12/05/2026 08:14, Patrick Steinhardt wrote:
> > ...
> >>> Introduce two new condition keywords:
> >>>
> >>>    - worktree:<pattern> 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:<pattern> is the case-insensitive variant.
> >>
> >> Seems sensible.
> >
> > We already support per-worktree config settings via
> > extensions.worktreeConfig, so it would be helpful to explain why it is
> > more convenient to set the config based on the worktree's path, rather
> > than just running "git config --worktree" inside the worktree. Do you
> > have multiple repositories with worktrees checked out under a common
> > prefix that you want to share the same config setting?

Yes, that is exactly why I added this feature. I contribute to the Linux kernel both as an employee and as an individual. I want to automatically use my company email address whenever I create a worktree under a specific directory.

Patrick SteinhardtMay 13, 2026, 05:56 UTC in reply to Chen Linxuan on lore

Re: [PATCH v3 2/2] config: add "worktree" and "worktree/i" includeIf conditions

On Wed, May 13, 2026 at 10:47:48AM +0800, Chen Linxuan wrote:
Show 9 quoted lines
> On Tue, 12 May 2026 09:14:03 +0200, Patrick Steinhardt wrote:
> > Just because it was explicitly mentioned: we might also want to have a
> > test that verifies this works with early-config parsing. We already have
> > a similar test for "gitdir:" in "conditional include, early config
> > reading".
> 
> As I wrote in the commit message, this is not going to work with
> early-config parsing. I am working on the fix. But I am not quite
> sure that this is a must-fix issue or not.

If it's not working we should have a test for this regardless, I think. We should verify the current behaviour around it and either mark it as `test_expect_success` if that behaviour is intended, or with `test_expect_failure` if it's not.

Thanks!
Patrick

Back to recent threads