git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH] config: introduce an Operating System-specific `includeIf` condition
Date: Mon, 21 Nov 2022 14:51:22 +0100	[thread overview]
Message-ID: <221121.86pmdgbdwa.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <pull.1429.git.1669037992587.gitgitgadget@gmail.com>


On Mon, Nov 21 2022, Johannes Schindelin via GitGitGadget wrote:

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> It is relatively common for users to maintain identical `~/.gitconfig`
> files across all of their setups, using the `includeIf` construct
> liberally to adjust the settings to the respective setup as needed.
>
> In case of Operating System-specific adjustments, Git currently offers
> no support to the users and they typically use a work-around like this:
>
> 	[includeIf "gitdir:/home/"]
> 		path = ~/.gitconfig-linux
> 	[includeIf "gitdir:/Users/"]
> 		path = ~/.gitconfig-mac
> 	[includeIf "gitdir:C:"]
> 		path = ~/.gitconfig-windows
>
> However, this is fragile, as it would not even allow to discern between
> Operating Systems that happen to host their home directories in
> `/home/`, such as Linux and the BSDs.

This looks like a really sensible thing to do, thanks.

> +`os`::
> +	The data that follows this keyword is taken as the name of an
> +	Operating System; If it matches the output of `uname -s`, the
> +	include condition is met.

Here yu say it "matches uname -s", but later in the test we can see
that's not the case. This is because compat/mingw.c is the source of
that "Windows" string, which we use for the uname() at the C level.

I don't think we've needed to document it before, but we should do so
here I'd think. Per
https://stackoverflow.com/questions/3466166/how-to-check-if-running-in-cygwin-mac-or-linux
users would follow these docs, try MinGw, then be confused, no?

> +static int include_by_os(const char *cond, size_t cond_len)
> +{
> +	struct utsname uname_info;
> +
> +	return !uname(&uname_info) &&
> +		!strncasecmp(uname_info.sysname, cond, cond_len) &&

Our config.mak.uname doesn't to case-insensitive uname matching, and
AFAIK these don't change between platforms versions. So why do we need
to support LINUX, LiNuX etc. in addition to the canonical Linux?

I'm not opposed to it if there's a good reason, but as we have "gitdir"
and "gitdir/i" shouldn't we make that "os/i" for consistency, if it's
needed?

> +test_expect_success '[includeIf "os:..."]' '
> +	test_config x.y 0 &&
> +	echo "[x] y = z" >.git/xyz &&
> +
> +	if test_have_prereq MINGW
> +	then
> +		uname_s=Windows
> +	else
> +		uname_s="$(uname -s)"
> +	fi &&
> +	test_config "includeIf.os:not-$uname_s.path" xyz &&

Re above: If it is important to support LINUX etc. these tests should
check it, they pass if it's converted to strncmp().

> +	test 0 = "$(git  config x.y)" &&

Hides segfaults, use test_cmp or test_cmp_config?

> +	test_config "includeIf.os:$uname_s.path" xyz &&
> +	test z = "$(git config x.y)"

Ditto segfault-hiding.

  reply	other threads:[~2022-11-21 14:10 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-21 13:39 [PATCH] config: introduce an Operating System-specific `includeIf` condition Johannes Schindelin via GitGitGadget
2022-11-21 13:51 ` Ævar Arnfjörð Bjarmason [this message]
2022-11-21 15:51   ` Phillip Wood
2022-11-21 19:18     ` Johannes Schindelin
2022-11-21 19:19 ` [PATCH v2] " Johannes Schindelin via GitGitGadget
2022-11-21 23:32   ` Jeff King
2022-11-23 11:54     ` Đoàn Trần Công Danh
2022-11-24  0:56       ` Jeff King
2022-11-22 14:01   ` Ævar Arnfjörð Bjarmason
2022-11-22 14:31     ` Phillip Wood
2022-11-23  0:16       ` Junio C Hamano
2022-11-23 15:07         ` Phillip Wood
2022-11-23 23:51           ` Junio C Hamano
2022-11-22 18:40   ` Philippe Blain
2022-11-23 10:40   ` Philip Oakley
2022-11-25  7:31     ` Junio C Hamano
2023-04-17  7:04       ` Samuel Ferencik
2023-04-17 18:46         ` Junio C Hamano
2023-04-18  2:04           ` Felipe Contreras
2023-04-19 12:22           ` Johannes Schindelin
2023-04-19 14:26             ` Chris Torek
2023-04-19 14:32               ` Samuel Ferencik
2023-04-19 15:21             ` rsbecker
2023-04-19 16:07             ` Junio C Hamano
2023-04-19 16:14             ` Junio C Hamano
2022-11-22  0:03 ` [PATCH] " Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=221121.86pmdgbdwa.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=johannes.schindelin@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).