hostname: includeIf condition — anyone already working on this?

hostname: includeIf condition — anyone already working on this?

[Isabella Caselli]

Hi all,

I'm looking for a small, relatively simple first contribution to Git
as part of an undergraduate thesis on community/contribution barriers,
and I'd like to work on the "hostname:" includeIf condition requested
in gitgitgadget/git#1665 [1]: matching includeIf on the machine's
hostname, mainly for sharing dotfiles across machines, e.g.:

    [includeIf "hostname:laptop"]
        path = ~/.gitconfig-laptop

I found a related proposal from 2022 for an includeIf condition based
on the operating system [2], which stalled over disagreements about
naming and case sensitivity. My understanding is that "hostname:" is a
narrower, separate condition (machine identity, not platform), so I
don't think it needs to revisit that discussion, but I wanted to check
before starting:

- Is it still relevant for the project?
   - If yes, is anyone already working on this issue?
- Any objection to the approach itself? The same machine can report
its hostname differently depending on how it's set up — sometimes just
the short name, sometimes with the full network address attached to it
— so it isn't obvious whether the condition should compare that value
exactly as the system reports it, or normalize it somehow before
comparing.

If nobody is on it, I'll put together a small patch modeled on the
existing onbranch: condition (dispatch in config.c, tests in
t1305-config-include.sh, docs in config.adoc).

Thanks,
Isabella Caselli
[1] https://github.com/gitgitgadget/git/issues/1665
[2] https://patchwork.kernel.org/project/git/patch/pull.1429.v2.git.1669058388327.gitgitgadget@gmail.com/

Re: hostname: includeIf condition — anyone already working on this?

[Jeff King]

On Mon, Sep 28, 2026 at 08:43:49PM -0300, Isabella Caselli wrote:

> I found a related proposal from 2022 for an includeIf condition based
> on the operating system [2], which stalled over disagreements about
> naming and case sensitivity. My understanding is that "hostname:" is a
> narrower, separate condition (machine identity, not platform), so I
> don't think it needs to revisit that discussion, but I wanted to check
> before starting:
> 
> - Is it still relevant for the project?
>    - If yes, is anyone already working on this issue?

I think it's a reasonable feature to have. I don't recall seeing anybody
else work on it recently (and a quick search of the list archive
confirms).

But see below.

> - Any objection to the approach itself? The same machine can report
> its hostname differently depending on how it's set up — sometimes just
> the short name, sometimes with the full network address attached to it
> — so it isn't obvious whether the condition should compare that value
> exactly as the system reports it, or normalize it somehow before
> comparing.

Yes, that is the tricky part. :) There were some patches in 2024:

  https://lore.kernel.org/git/20240307205006.467443-1-ignacio@iencinas.com/

where the issue came up. Based on my recollection and a quick skim of
the thread, I think the consensus was that it's OK to document that it
is system-dependent whether we'll match against a short of fully
qualified hostname. But exposing our view of the hostname via git-var
(e.g., "git var GIT_HOSTNAME") might be a helpful debugging aid.

It looks like after review on v3 of the series we never saw more. I'd
guess the author (cc'd) just never got around to pushing it forward.

-Peff

Re: hostname: includeIf condition — anyone already working on this?

[Ignacio Encinas]

Hello,

On Tue Sep 29, 2026 at 2:44 AM IST, Jeff King wrote:
> On Mon, Sep 28, 2026 at 08:43:49PM -0300, Isabella Caselli wrote:
>
>> - Any objection to the approach itself? The same machine can report
>> its hostname differently depending on how it's set up — sometimes just
>> the short name, sometimes with the full network address attached to it
>> — so it isn't obvious whether the condition should compare that value
>> exactly as the system reports it, or normalize it somehow before
>> comparing.
>
> Yes, that is the tricky part. :) There were some patches in 2024:
>
>   https://lore.kernel.org/git/20240307205006.467443-1-ignacio@iencinas.com/
>
> where the issue came up. Based on my recollection and a quick skim of
> the thread, I think the consensus was that it's OK to document that it
> is system-dependent whether we'll match against a short of fully
> qualified hostname. But exposing our view of the hostname via git-var
> (e.g., "git var GIT_HOSTNAME") might be a helpful debugging aid.
>
> It looks like after review on v3 of the series we never saw more. I'd
> guess the author (cc'd) just never got around to pushing it forward.

That's what happened. Similar to Isabella, I was looking for a small
contribution but it ended up being more complicated than expected. I got
a bit overwhelmed and decided to drop it.

I kept wondering if I should have communicated that, so apologies if
that was the case.

I hope the discussion from 2024 is at least helpful now if this ends up
being implemented by Isabella.

Best regards,
Ignacio

Re: hostname: includeIf condition — anyone already working on this?

[Jeff King]

On Tue, Sep 29, 2026 at 01:14:34PM +0100, Ignacio Encinas wrote:

> > Yes, that is the tricky part. :) There were some patches in 2024:
> >
> >   https://lore.kernel.org/git/20240307205006.467443-1-ignacio@iencinas.com/
> >
> > where the issue came up. Based on my recollection and a quick skim of
> > the thread, I think the consensus was that it's OK to document that it
> > is system-dependent whether we'll match against a short of fully
> > qualified hostname. But exposing our view of the hostname via git-var
> > (e.g., "git var GIT_HOSTNAME") might be a helpful debugging aid.
> >
> > It looks like after review on v3 of the series we never saw more. I'd
> > guess the author (cc'd) just never got around to pushing it forward.
> 
> That's what happened. Similar to Isabella, I was looking for a small
> contribution but it ended up being more complicated than expected. I got
> a bit overwhelmed and decided to drop it.
> 
> I kept wondering if I should have communicated that, so apologies if
> that was the case.

Nah, it's not a big deal. This is open source, so everybody is here
voluntarily, and it's normal for people to come in and out as time and
interest permits. Plus the very reason that people end up dropping a
series (getting overwhelmed) often makes it hard to decide whether and
when to write the "I'm dropping this" email. :)

> I hope the discussion from 2024 is at least helpful now if this ends up
> being implemented by Isabella.

Yeah, I think there's a lot of good discussion there, and the patches
themselves can probably give a boost to another attempt. Even if we did
not finish it back then, thank you for the work so far.

-Peff

Re: hostname: includeIf condition — anyone already working on this?

[Junio C Hamano]

"Ignacio Encinas" <ignacio@iencinas.com> writes:

> On Tue Sep 29, 2026 at 2:44 AM IST, Jeff King wrote:
> ...
>> It looks like after review on v3 of the series we never saw more. I'd
>> guess the author (cc'd) just never got around to pushing it forward.
>
> That's what happened. Similar to Isabella, I was looking for a small
> contribution but it ended up being more complicated than expected. I got
> a bit overwhelmed and decided to drop it.
> ...
> I hope the discussion from 2024 is at least helpful now if this ends up
> being implemented by Isabella.

I was re-reading the thread yesterday.  It looked like we were _so_
close to the finish line before the discussion stopped, which is a
shame.  All the good bits were already designed and the only thing
left was to assemble and package them up.

Re: hostname: includeIf condition — anyone already working on this?

[Isabella Caselli]

Interesting, I didn't know there had already been a discussion
about this issue. Thank you, Jeff, for pointing me to the 2024 series.

Junio C Hamano <gitster@pobox.com> writes:

> "Ignacio Encinas" <ignacio@iencinas.com> writes:
>
>> That's what happened. Similar to Isabella, I was looking for a small
>> contribution but it ended up being more complicated than expected. I got
>> a bit overwhelmed and decided to drop it.
>> ...
>> I hope the discussion from 2024 is at least helpful now if this ends up
>> being implemented by Isabella.

Ignacio, if you don't mind, I'd like to continue the work based on
yours and credit you when submitting the series.

> I was re-reading the thread yesterday.  It looked like we were _so_
> close to the finish line before the discussion stopped, which is a
> shame.  All the good bits were already designed and the only thing
> left was to assemble and package them up.

That's encouraging to hear! Sounds like a plan to go through the 2024
thread, including Jeff's suggestion of exposing the hostname via "git var",
and send an updated version of the series addressing the comments on v3.

Thanks,
Isabella

[PATCH 0/3] Add hostname condition to includeIf

[Isabella Caselli]

This series adds a "hostname:" condition to includeIf, allowing a
configuration file to be included only on machines whose hostname
matches a pattern. It also adds GIT_HOSTNAME to "git var", so users
can see which hostname Git uses for matching.

The series is based on Ignacio Encinas's v3 from March 2024 [1].
Ignacio dropped the series and agreed to let me give it a try,
so I am sending it as a new series.
The "hostname:" patch retains his work and credits him with
Based-on-patch-by.

Changes since Ignacio's v3:

 - Drop "test-tool xgethostname". Eric pointed out that exposing the
   hostname to users would make the helper unnecessary, and suggested
   adding GIT_HOSTNAME to "git var", which I agree is the best way to
   make this information available to users. Patch 1 adds it, and the
   tests use it instead of the helper.

 - Make "git var -l" omit GIT_HOSTNAME when the hostname cannot be
   determined, rather than failing, as Jeff suggested.

 - Make t6500 use "git var GIT_HOSTNAME || echo unknown", as Jeff
   suggested and Junio agreed.

 - Document that the hostname may be short or fully qualified, using
   Jeff's proposed wording, and point to "git var GIT_HOSTNAME"
   instead of gethostname(2), which Eric noted would not be helpful
   to users.

 - Use xmemdupz() in include_by_hostname(), as Jeff suggested.

 - In t1305, read the hostname into a variable before each
   here-document, so that failures are not silently ignored, as
   Junio pointed out.

One open question is case sensitivity. Matching is case-sensitive,
like "onbranch:", so "hostname:MyHost" would not match a machine that
reports "myhost", even though DNS names are case-insensitive. Keeping
it case-sensitive seems reasonable to me, but I was not sure. Should
it stay as is, ignore case, or have a "hostname/i:" variant, like
"gitdir/i:"?

[1] https://lore.kernel.org/git/20240319183722.211300-1-ignacio@iencinas.com/

Isabella Caselli (3):
  var: add GIT_HOSTNAME
  t6500: get hostname from "git var"
  config: learn the "hostname:" includeIf condition

 Documentation/config.adoc  | 14 ++++++++++++
 Documentation/git-var.adoc |  5 +++++
 builtin/var.c              | 13 +++++++++++
 config.c                   | 17 +++++++++++++++
 t/t0007-git-var.sh         |  5 +++++
 t/t1305-config-include.sh  | 44 ++++++++++++++++++++++++++++++++++++++
 t/t6500-gc.sh              |  2 +-
 7 files changed, 99 insertions(+), 1 deletion(-)


base-commit: 5a7d1e8045ce66c908f62598e26cbb8df7b39a90
-- 
2.43.0

[PATCH 1/3] var: add GIT_HOSTNAME

[Isabella Caselli]

Git asks the system for the name of the machine it runs on in a few
places. For example, "git gc" records it in "gc.pid" to tell whether
the gc holding the lock runs on the same machine. Users have no way
to see which name Git uses, and depending on how the system is
configured, it may be a short name ("myhost") or a fully qualified
one ("myhost.example.com").

This matters more once the config can depend on the hostname, which
a later commit adds as an includeIf condition. Without a way to see
the value Git uses, users would have to guess what to write in their
config file.

Add a GIT_HOSTNAME variable to "git var" that prints the hostname
Git sees. If the hostname can't be determined, "git var GIT_HOSTNAME"
exits with a non-zero status, and "git var -l" omits the variable
instead of failing.

An option to "git config" to show the hostname was also discussed,
but "git var" was chosen, since the hostname is not specific to
the configuration code.

The test only checks that a non-empty value is printed. The test has
no independent way to know the expected hostname, as the "hostname"
command may not agree with what Git sees on every platform. The
includeIf tests added later check that the value matches what the
configuration code uses.

Suggested-by: Eric Sunshine <sunshine@sunshineco.com>
Suggested-by: Jeff King <peff@peff.net>
Signed-off-by: Isabella Caselli <bellacaselli20@gmail.com>
---
 Documentation/git-var.adoc |  3 +++
 builtin/var.c              | 13 +++++++++++++
 t/t0007-git-var.sh         |  5 +++++
 3 files changed, 21 insertions(+)

diff --git a/Documentation/git-var.adoc b/Documentation/git-var.adoc
index 697c10aded..e813ab4fd2 100644
--- a/Documentation/git-var.adoc
+++ b/Documentation/git-var.adoc
@@ -84,6 +84,9 @@ endif::git-default-pager[]
 `GIT_CONFIG_GLOBAL`::
     The path to the global (per-user) configuration files, if any.
 
+`GIT_HOSTNAME`::
+    The hostname of the machine, as reported by the operating system.
+
 Most path values contain only one value. However, some can contain multiple
 values, which are separated by newlines, and are listed in order from highest to
 lowest priority.  Callers should be prepared for any such path value to contain
diff --git a/builtin/var.c b/builtin/var.c
index cc3a43cde2..b427ebd61e 100644
--- a/builtin/var.c
+++ b/builtin/var.c
@@ -115,6 +115,15 @@ static char *git_config_val_global(int ident_flag UNUSED)
 	return strbuf_detach(&buf, &unused);
 }
 
+static char *hostname(int ident_flag UNUSED)
+{
+	char buf[HOST_NAME_MAX + 1];
+
+	if (xgethostname(buf, sizeof(buf)))
+		return NULL;
+	return xstrdup(buf);
+}
+
 struct git_var {
 	const char *name;
 	char *(*read)(int);
@@ -166,6 +175,10 @@ static struct git_var git_vars[] = {
 		.read = git_config_val_global,
 		.multivalued = 1,
 	},
+	{
+		.name = "GIT_HOSTNAME",
+		.read = hostname,
+	},
 	{
 		.name = "",
 		.read = NULL,
diff --git a/t/t0007-git-var.sh b/t/t0007-git-var.sh
index 2b60317758..f50c62a25e 100755
--- a/t/t0007-git-var.sh
+++ b/t/t0007-git-var.sh
@@ -224,6 +224,11 @@ test_expect_success 'GIT_CONFIG_GLOBAL points to the correct location' '
 	)
 '
 
+test_expect_success 'GIT_HOSTNAME is not empty' '
+	hostname=$(git var GIT_HOSTNAME) &&
+	test -n "$hostname"
+'
+
 # For git var -l, we check only a representative variable;
 # testing the whole output would make our test too brittle with
 # respect to unrelated changes in the test suite's environment.
-- 
2.43.0

[PATCH 2/3] t6500: get hostname from "git var"

[Isabella Caselli]

The test "background auto gc respects lock for all operations" simulates
a concurrent gc by writing our shell's pid and hostname to "gc.pid".
It gets the hostname from the "hostname" command, falling back to
"unknown" if the command fails.

"git gc" gets its hostname from the system and only checks whether the
pid is alive if the two hostnames match. Otherwise, it assumes the
lock belongs to a gc running on another machine. Since the test passes
in either case, a missing "hostname" command or a mismatch between
its output and the system hostname can cause the test to silently
exercise the wrong case.

Use "git var GIT_HOSTNAME" to get the same hostname as "git gc".
Keep the "unknown" fallback, which is also used by "git gc" when it
cannot determine the hostname.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Isabella Caselli <bellacaselli20@gmail.com>
---
 t/t6500-gc.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t6500-gc.sh b/t/t6500-gc.sh
index a7142ab815..f928089bf0 100755
--- a/t/t6500-gc.sh
+++ b/t/t6500-gc.sh
@@ -413,7 +413,7 @@ test_expect_success 'background auto gc respects lock for all operations' '
 
 	# now fake a concurrent gc that holds the lock; we can use our
 	# shell pid so that it looks valid.
-	hostname=$(hostname || echo unknown) &&
+	hostname=$(git var GIT_HOSTNAME || echo unknown) &&
 	shell_pid=$$ &&
 	if test_have_prereq MINGW && test -f /proc/$shell_pid/winpid
 	then
-- 
2.43.0

Re: [PATCH 2/3] t6500: get hostname from "git var"

[Junio C Hamano]

Isabella Caselli <bellacaselli20@gmail.com> writes:

> The test "background auto gc respects lock for all operations" simulates
> a concurrent gc by writing our shell's pid and hostname to "gc.pid".
> It gets the hostname from the "hostname" command, falling back to
> "unknown" if the command fails.
>
> "git gc" gets its hostname from the system and only checks whether the
> pid is alive if the two hostnames match. Otherwise, it assumes the
> lock belongs to a gc running on another machine. Since the test passes
> in either case, a missing "hostname" command or a mismatch between
> its output and the system hostname can cause the test to silently
> exercise the wrong case.

"exercise the wrong case", meaning...  where hostname(1) output is
different from "git var GIT_HOSTNAME" (aka xgethostname()), we would
have written bogus name in .git/gc.pid file, simulating the case where
gc.pid was written by a process running on a different machine.

What is the implications of doing so?
>
> Use "git var GIT_HOSTNAME" to get the same hostname as "git gc".
> Keep the "unknown" fallback, which is also used by "git gc" when it
> cannot determine the hostname.
>
> Helped-by: Jeff King <peff@peff.net>
> Signed-off-by: Isabella Caselli <bellacaselli20@gmail.com>
> ---
>  t/t6500-gc.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t6500-gc.sh b/t/t6500-gc.sh
> index a7142ab815..f928089bf0 100755
> --- a/t/t6500-gc.sh
> +++ b/t/t6500-gc.sh
> @@ -413,7 +413,7 @@ test_expect_success 'background auto gc respects lock for all operations' '
>  
>  	# now fake a concurrent gc that holds the lock; we can use our
>  	# shell pid so that it looks valid.
> -	hostname=$(hostname || echo unknown) &&
> +	hostname=$(git var GIT_HOSTNAME || echo unknown) &&
>  	shell_pid=$$ &&
>  	if test_have_prereq MINGW && test -f /proc/$shell_pid/winpid
>  	then

Re: [PATCH 2/3] t6500: get hostname from "git var"

[Isabella Caselli]

Junio C Hamano <gitster@pobox.com> writes:

> "exercise the wrong case", meaning...  where hostname(1) output is
> different from "git var GIT_HOSTNAME" (aka xgethostname()), we would
> have written bogus name in .git/gc.pid file, simulating the case where
> gc.pid was written by a process running on a different machine.
>
> What is the implications of doing so?

If the hostnames differ, lock_repo_for_gc() assumes the lock belongs
to a process on another machine. In that case, strcmp(locking_host,
my_host) is already true, so the remaining conditions are never
evaluated, such as !kill(pid, 0).
So the test would still pass, but wouldn't actually check whether Git
detects that the pid belongs to a running process on the same machine,
which is the behavior it is meant to verify.

Should I adjust the commit message to clarify this?

Re: [PATCH 2/3] t6500: get hostname from "git var"

[Junio C Hamano]

Isabella Caselli <bellacaselli20@gmail.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> "exercise the wrong case", meaning...  where hostname(1) output is
>> different from "git var GIT_HOSTNAME" (aka xgethostname()), we would
>> have written bogus name in .git/gc.pid file, simulating the case where
>> gc.pid was written by a process running on a different machine.
>>
>> What is the implications of doing so?
>
> If the hostnames differ, lock_repo_for_gc() assumes the lock belongs
> to a process on another machine. In that case, strcmp(locking_host,
> my_host) is already true, so the remaining conditions are never
> evaluated, such as !kill(pid, 0).
> So the test would still pass, but wouldn't actually check whether Git
> detects that the pid belongs to a running process on the same machine,
> which is the behavior it is meant to verify.
>
> Should I adjust the commit message to clarify this?

Absolutely.  The only reason I asked was because I didn't understand
what you wanted to say in the proposed log message, which means it
is very likely other people would have difficulty reading "git log"
if we committed it as-is.

Thanks.

[PATCH 3/3] config: learn the "hostname:" includeIf condition

[Isabella Caselli]

When the same home directory is shared across multiple machines, they
all read the same ~/.gitconfig. Settings that should differ between
machines therefore need a way to make that file behave differently
on each host. The same problem affects people who keep their dotfiles
in a repository and check them out on multiple machines.

Add a "hostname:" keyword to includeIf. The value that follows is a
pattern supporting standard glob wildcards, and the condition is met
when the machine's hostname matches it. If the hostname cannot be
determined, the condition is not met.

Depending on the system configuration, the hostname may be either a
short name or a fully qualified domain name. Making the name fully
qualified ourselves was considered, but it could require a DNS lookup
while reading the configuration. Instead, match the name as the
system reports it, document this, and point to "git var GIT_HOSTNAME"
as a way to check the value being matched.

The tests obtain the hostname with "git var GIT_HOSTNAME" before
writing the configuration, so that a failure to retrieve it makes
the test fail instead of going unnoticed inside the here-document.

Based-on-patch-by: Ignacio Encinas <ignacio@iencinas.com>
Signed-off-by: Isabella Caselli <bellacaselli20@gmail.com>
---
 Documentation/config.adoc  | 14 ++++++++++++
 Documentation/git-var.adoc |  2 ++
 config.c                   | 17 +++++++++++++++
 t/t1305-config-include.sh  | 44 ++++++++++++++++++++++++++++++++++++++
 4 files changed, 77 insertions(+)

diff --git a/Documentation/config.adoc b/Documentation/config.adoc
index f67dcd2f8e..aa6360e230 100644
--- a/Documentation/config.adoc
+++ b/Documentation/config.adoc
@@ -232,6 +232,16 @@ As for the naming of this keyword, it is for forwards compatibility with
 a naming scheme that supports more variable-based include conditions,
 but currently Git only supports the exact keyword described above.
 
+`hostname`::
+	The data that follows the keyword `hostname:` is taken to be a
+	pattern with standard globbing wildcards. If the hostname of
+	the machine matches the pattern, the include condition is met.
++
+Depending on how your system is configured, the hostname used for
+matching may be short (e.g., "myhost") or a fully qualified domain
+name ("myhost.example.com"). Run `git var GIT_HOSTNAME` to see the
+hostname Git uses (see linkgit:git-var[1]).
+
 A few more notes on matching via `gitdir` and `gitdir/i`:
 
  * Symlinks in `$GIT_DIR` are not resolved before matching.
@@ -315,6 +325,10 @@ Example
 	path = foo.inc
 [remote "origin"]
 	url = https://example.com/git
+
+; include only if the hostname of the machine matches some-hostname
+[includeIf "hostname:some-hostname"]
+	path = foo.inc
 ----
 
 Values
diff --git a/Documentation/git-var.adoc b/Documentation/git-var.adoc
index e813ab4fd2..fc2def16d3 100644
--- a/Documentation/git-var.adoc
+++ b/Documentation/git-var.adoc
@@ -86,6 +86,8 @@ endif::git-default-pager[]
 
 `GIT_HOSTNAME`::
     The hostname of the machine, as reported by the operating system.
+    This is the hostname matched by `includeIf "hostname:..."` (see
+    linkgit:git-config[1]).
 
 Most path values contain only one value. However, some can contain multiple
 values, which are separated by newlines, and are listed in order from highest to
diff --git a/config.c b/config.c
index e0bb29b53d..c891f63e60 100644
--- a/config.c
+++ b/config.c
@@ -316,6 +316,21 @@ static int include_by_branch(struct config_include_data *data,
 	return ret;
 }
 
+static int include_by_hostname(const char *cond, size_t cond_len)
+{
+	int ret;
+	char my_host[HOST_NAME_MAX + 1];
+	char *pattern;
+
+	if (xgethostname(my_host, sizeof(my_host)))
+		return 0;
+
+	pattern = xmemdupz(cond, cond_len);
+	ret = !wildmatch(pattern, my_host, 0);
+	free(pattern);
+	return ret;
+}
+
 static int add_remote_url(const char *var, const char *value,
 			  const struct config_context *ctx UNUSED, void *data)
 {
@@ -411,6 +426,8 @@ static int include_condition_is_true(const struct key_value_info *kvi,
 	else if (skip_prefix_mem(cond, cond_len, "hasconfig:remote.*.url:", &cond,
 				   &cond_len))
 		return include_by_remote_url(inc, cond, cond_len);
+	else if (skip_prefix_mem(cond, cond_len, "hostname:", &cond, &cond_len))
+		return include_by_hostname(cond, cond_len);
 
 	/* unknown conditionals are always false */
 	return 0;
diff --git a/t/t1305-config-include.sh b/t/t1305-config-include.sh
index 507b8ebd06..01069237ba 100755
--- a/t/t1305-config-include.sh
+++ b/t/t1305-config-include.sh
@@ -524,4 +524,48 @@ test_expect_success 'conditional include, worktree without repository but explic
 	test_must_fail nongit git --git-dir=nonexistent config get foo.bar
 '
 
+test_expect_success 'conditional include, hostname' '
+	hostname=$(git var GIT_HOSTNAME) &&
+	cat >>.git/config <<-EOF &&
+	[includeIf "hostname:${hostname}a"]
+		path = bar12
+	EOF
+	cat >>.git/bar12 <<-EOF &&
+	[test]
+		twelve=12
+	EOF
+
+	test_must_fail git config test.twelve &&
+
+	cat >>.git/config <<-EOF &&
+	[includeIf "hostname:$hostname"]
+		path = bar12
+	EOF
+	echo 12 >expect &&
+	git config test.twelve >actual &&
+	test_cmp expect actual
+'
+
+test_expect_success 'conditional include, hostname, wildcard' '
+	hostname=$(git var GIT_HOSTNAME) &&
+	cat >>.git/config <<-EOF &&
+	[includeIf "hostname:${hostname}a*"]
+		path = bar13
+	EOF
+	cat >>.git/bar13 <<-EOF &&
+	[test]
+		thirteen = 13
+	EOF
+
+	test_must_fail git config test.thirteen &&
+
+	cat >>.git/config <<-EOF &&
+	[includeIf "hostname:$hostname*"]
+		path = bar13
+	EOF
+	echo 13 >expect &&
+	git config test.thirteen >actual &&
+	test_cmp expect actual
+'
+
 test_done
-- 
2.43.0

Re: [PATCH 3/3] config: learn the "hostname:" includeIf condition

[Junio C Hamano]

Isabella Caselli <bellacaselli20@gmail.com> writes:

> +static int include_by_hostname(const char *cond, size_t cond_len)
> +{
> +	int ret;
> +	char my_host[HOST_NAME_MAX + 1];
> +	char *pattern;
> +
> +	if (xgethostname(my_host, sizeof(my_host)))
> +		return 0;
> +
> +	pattern = xmemdupz(cond, cond_len);
> +	ret = !wildmatch(pattern, my_host, 0);
> +	free(pattern);
> +	return ret;
> +}
> +
>  static int add_remote_url(const char *var, const char *value,
>  			  const struct config_context *ctx UNUSED, void *data)
>  {
> @@ -411,6 +426,8 @@ static int include_condition_is_true(const struct key_value_info *kvi,
>  	else if (skip_prefix_mem(cond, cond_len, "hasconfig:remote.*.url:", &cond,
>  				   &cond_len))
>  		return include_by_remote_url(inc, cond, cond_len);
> +	else if (skip_prefix_mem(cond, cond_len, "hostname:", &cond, &cond_len))
> +		return include_by_hostname(cond, cond_len);

Neat.  With this include_condition_is_true() helper, adding such
conditional inclusion is made very easy.  Quite nice.