{"thread":{"id":"58830","subject":"[PATCH] config: introduce an Operating System-specific `includeIf` condition","startedAt":"2022-11-21T13:40:24Z","lastAt":"2023-04-19T16:14:19Z","messageCount":26,"participants":["Johannes Schindelin via GitGitGadget","Ævar Arnfjörð Bjarmason","Phillip Wood","Johannes Schindelin","Jeff King","Junio C Hamano","Philippe Blain","Philip Oakley","Đoàn Trần Công Danh","Samuel Ferencik","Felipe Contreras","Chris Torek","rsbecker@nexbridge.com"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"467687","messageId":"pull.1429.git.1669037992587.gitgitgadget@gmail.com","threadId":"58830","inReplyTo":null,"subject":"[PATCH] config: introduce an Operating System-specific `includeIf` condition","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-11-21T13:39:52Z","receivedAt":"2022-11-21T13:40:24Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin \n\nIt is relatively common for users to maintain identical `~/.gitconfig`\nfiles across all of their setups, using the `includeIf` construct\nliberally to adjust the settings to the respective setup as needed.\n\nIn case of Operating System-specific adjustments, Git currently offers\nno support to the users and they typically use a work-around like this:\n\n\t[includeIf \"gitdir:/home/\"]\n\t\tpath = ~/.gitconfig-linux\n\t[includeIf \"gitdir:/Users/\"]\n\t\tpath = ~/.gitconfig-mac\n\t[includeIf \"gitdir:C:\"]\n\t\tpath = ~/.gitconfig-windows\n\nHowever, this is fragile, as it would not even allow to discern between\nOperating Systems that happen to host their home directories in\n`/home/`, such as Linux and the BSDs.\n\nLet's introduce a new condition: `os:` where `` is the\nsystem name, i.e. the output of `uname -s`.\n\nThis addresses https://github.com/git-for-windows/git/issues/4125\n\nSigned-off-by: Johannes Schindelin \n---\n config: introduce an Operating System-specific includeIf condition\n \n I was about to write up guidelines how to write this patch, but it\n turned out that it was much faster to write the patch instead.\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-1429%2Fdscho%2Finclude-if-os-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1429/dscho/include-if-os-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/1429\n\n Documentation/config.txt | 5 +++++\n config.c | 11 +++++++++++\n t/t1309-early-config.sh | 16 ++++++++++++++++\n 3 files changed, 32 insertions(+)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex e376d547ce0..2db73d8228e 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -186,6 +186,11 @@ As for the naming of this keyword, it is for forwards compatibiliy with\n a naming scheme that supports more variable-based include conditions,\n but currently Git only supports the exact keyword described above.\n \n+`os`::\n+\tThe data that follows this keyword is taken as the name of an\n+\tOperating System; If it matches the output of `uname -s`, the\n+\tinclude condition is met.\n+\n A few more notes on matching via `gitdir` and `gitdir/i`:\n \n * Symlinks in `$GIT_DIR` are not resolved before matching.\ndiff --git a/config.c b/config.c\nindex 9b0e9c93285..9ab311ae99b 100644\n--- a/config.c\n+++ b/config.c\n@@ -394,6 +394,15 @@ static int include_by_remote_url(struct config_include_data *inc,\n \t\t\t\t\t inc->remote_urls);\n }\n \n+static int include_by_os(const char *cond, size_t cond_len)\n+{\n+\tstruct utsname uname_info;\n+\n+\treturn !uname(&uname_info) &&\n+\t\t!strncasecmp(uname_info.sysname, cond, cond_len) &&\n+\t\t!uname_info.sysname[cond_len];\n+}\n+\n static int include_condition_is_true(struct config_include_data *inc,\n \t\t\t\t const char *cond, size_t cond_len)\n {\n@@ -408,6 +417,8 @@ static int include_condition_is_true(struct config_include_data *inc,\n \telse if (skip_prefix_mem(cond, cond_len, \"hasconfig:remote.*.url:\", &cond,\n \t\t\t\t &cond_len))\n \t\treturn include_by_remote_url(inc, cond, cond_len);\n+\telse if (skip_prefix_mem(cond, cond_len, \"os:\", &cond, &cond_len))\n+\t\treturn include_by_os(cond, cond_len);\n \n \t/* unknown conditionals are always false */\n \treturn 0;\ndiff --git a/t/t1309-early-config.sh b/t/t1309-early-config.sh\nindex 537435b90ae..7da67af06e7 100755\n--- a/t/t1309-early-config.sh\n+++ b/t/t1309-early-config.sh\n@@ -100,4 +100,20 @@ test_expect_success 'onbranch config outside of git repo' '\n \tnongit git help\n '\n \n+test_expect_success '[includeIf \"os:...\"]' '\n+\ttest_config x.y 0 &&\n+\techo \"[x] y = z\" >.git/xyz &&\n+\n+\tif test_have_prereq MINGW\n+\tthen\n+\t\tuname_s=Windows\n+\telse\n+\t\tuname_s=\"$(uname -s)\"\n+\tfi &&\n+\ttest_config \"includeIf.os:not-$uname_s.path\" xyz &&\n+\ttest 0 = \"$(git config x.y)\" &&\n+\ttest_config \"includeIf.os:$uname_s.path\" xyz &&\n+\ttest z = \"$(git config x.y)\"\n+'\n+\n test_done\n\nbase-commit: e4a4b31577c7419497ac30cebe30d755b97752c5\n-- \ngitgitgadget\n"},{"id":"467689","messageId":"221121.86pmdgbdwa.gmgdl@evledraar.gmail.com","threadId":"58830","inReplyTo":"pull.1429.git.1669037992587.gitgitgadget@gmail.com","subject":"Re: [PATCH] config: introduce an Operating System-specific `includeIf` condition","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-11-21T13:51:22Z","receivedAt":"2022-11-21T14:10:33Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Nov 21 2022, Johannes Schindelin via GitGitGadget wrote:\n\n> From: Johannes Schindelin \n>\n> It is relatively common for users to maintain identical `~/.gitconfig`\n> files across all of their setups, using the `includeIf` construct\n> liberally to adjust the settings to the respective setup as needed.\n>\n> In case of Operating System-specific adjustments, Git currently offers\n> no support to the users and they typically use a work-around like this:\n>\n> \t[includeIf \"gitdir:/home/\"]\n> \t\tpath = ~/.gitconfig-linux\n> \t[includeIf \"gitdir:/Users/\"]\n> \t\tpath = ~/.gitconfig-mac\n> \t[includeIf \"gitdir:C:\"]\n> \t\tpath = ~/.gitconfig-windows\n>\n> However, this is fragile, as it would not even allow to discern between\n> Operating Systems that happen to host their home directories in\n> `/home/`, such as Linux and the BSDs.\n\nThis looks like a really sensible thing to do, thanks.\n\n> +`os`::\n> +\tThe data that follows this keyword is taken as the name of an\n> +\tOperating System; If it matches the output of `uname -s`, the\n> +\tinclude condition is met.\n\nHere yu say it \"matches uname -s\", but later in the test we can see\nthat's not the case. This is because compat/mingw.c is the source of\nthat \"Windows\" string, which we use for the uname() at the C level.\n\nI don't think we've needed to document it before, but we should do so\nhere I'd think. Per\nhttps://stackoverflow.com/questions/3466166/how-to-check-if-running-in-cygwin-mac-or-linux\nusers would follow these docs, try MinGw, then be confused, no?\n\n> +static int include_by_os(const char *cond, size_t cond_len)\n> +{\n> +\tstruct utsname uname_info;\n> +\n> +\treturn !uname(&uname_info) &&\n> +\t\t!strncasecmp(uname_info.sysname, cond, cond_len) &&\n\nOur config.mak.uname doesn't to case-insensitive uname matching, and\nAFAIK these don't change between platforms versions. So why do we need\nto support LINUX, LiNuX etc. in addition to the canonical Linux?\n\nI'm not opposed to it if there's a good reason, but as we have \"gitdir\"\nand \"gitdir/i\" shouldn't we make that \"os/i\" for consistency, if it's\nneeded?\n\n> +test_expect_success '[includeIf \"os:...\"]' '\n> +\ttest_config x.y 0 &&\n> +\techo \"[x] y = z\" >.git/xyz &&\n> +\n> +\tif test_have_prereq MINGW\n> +\tthen\n> +\t\tuname_s=Windows\n> +\telse\n> +\t\tuname_s=\"$(uname -s)\"\n> +\tfi &&\n> +\ttest_config \"includeIf.os:not-$uname_s.path\" xyz &&\n\nRe above: If it is important to support LINUX etc. these tests should\ncheck it, they pass if it's converted to strncmp().\n\n> +\ttest 0 = \"$(git config x.y)\" &&\n\nHides segfaults, use test_cmp or test_cmp_config?\n\n> +\ttest_config \"includeIf.os:$uname_s.path\" xyz &&\n> +\ttest z = \"$(git config x.y)\"\n\nDitto segfault-hiding.\n"},{"id":"467694","messageId":"aa054864-203b-3c06-0706-6cc40310a830@dunelm.org.uk","threadId":"58830","inReplyTo":"221121.86pmdgbdwa.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH] config: introduce an Operating System-specific `includeIf` condition","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2022-11-21T15:51:23Z","receivedAt":"2022-11-21T15:51:33Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Dscho and Ævar\n\nOn 21/11/2022 13:51, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Mon, Nov 21 2022, Johannes Schindelin via GitGitGadget wrote:\n> \n>> From: Johannes Schindelin \n>>\n>> It is relatively common for users to maintain identical `~/.gitconfig`\n>> files across all of their setups, using the `includeIf` construct\n>> liberally to adjust the settings to the respective setup as needed.\n>>\n>> In case of Operating System-specific adjustments, Git currently offers\n>> no support to the users and they typically use a work-around like this:\n>>\n>> \t[includeIf \"gitdir:/home/\"]\n>> \t\tpath = ~/.gitconfig-linux\n>> \t[includeIf \"gitdir:/Users/\"]\n>> \t\tpath = ~/.gitconfig-mac\n>> \t[includeIf \"gitdir:C:\"]\n>> \t\tpath = ~/.gitconfig-windows\n>>\n>> However, this is fragile, as it would not even allow to discern between\n>> Operating Systems that happen to host their home directories in\n>> `/home/`, such as Linux and the BSDs.\n> \n> This looks like a really sensible thing to do, thanks.\n\nYes, it looks like a really useful enhancement\n\n>> +`os`::\n>> +\tThe data that follows this keyword is taken as the name of an\n>> +\tOperating System; If it matches the output of `uname -s`, the\n\nMaybe add e.g. \"Windows or Linux\" after Operating System?\n\n>> +static int include_by_os(const char *cond, size_t cond_len)\n>> +{\n>> +\tstruct utsname uname_info;\n>> +\n>> +\treturn !uname(&uname_info) &&\n>> +\t\t!strncasecmp(uname_info.sysname, cond, cond_len) &&\n> \n> Our config.mak.uname doesn't to case-insensitive uname matching, and\n> AFAIK these don't change between platforms versions. So why do we need\n> to support LINUX, LiNuX etc. in addition to the canonical Linux?\n> \n> I'm not opposed to it if there's a good reason, but as we have \"gitdir\"\n> and \"gitdir/i\" shouldn't we make that \"os/i\" for consistency, if it's\n> needed?\n\nWhy should we penalize users who write \"linux\" rather than \"Linux\"? \nMaking the comparison case insensitive seems eminently sensible. File \nsystems can be case sensitive so having the option to specify whether a \nmatch for \"gitdir\" is case sensitive or not makes sense there but not \nfor the name of an operating system.\n\nBest Wishes\n\nPhillip\n"},{"id":"467715","messageId":"0p39pqos-5rn9-q0np-qon6-0r0qqq644on9@tzk.qr","threadId":"58830","inReplyTo":"aa054864-203b-3c06-0706-6cc40310a830@dunelm.org.uk","subject":"Re: [PATCH] config: introduce an Operating System-specific `includeIf` condition","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-11-21T19:18:34Z","receivedAt":"2022-11-21T19:18:53Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Phillip & Ævar,\n\n[Ævar, in your mail, which I suggest could have used some editing for\nspelling and brevity, I found only the concern about `uname -s`\nrelevant, and since Phillip's suggestion is more actionable than the\nsomewhat diffuse excurse about something to do with something in a\nStackOverflow thread, I will only reply here.]\n\nOn Mon, 21 Nov 2022, Phillip Wood wrote:\n\n> On 21/11/2022 13:51, Ævar Arnfjörð Bjarmason wrote:\n> >\n> > On Mon, Nov 21 2022, Johannes Schindelin via GitGitGadget wrote:\n> >\n> > [...]\n> > > +`os`::\n> > > +\tThe data that follows this keyword is taken as the name of an\n> > > +\tOperating System; If it matches the output of `uname -s`, the\n>\n> Maybe add e.g. \"Windows or Linux\" after Operating System?\n\nExcellent idea. I'll also drop mentioning `uname -s` because it assumes more\nabout the users' setup than can be assumed.\n\nI also replaced a space character in the added test case that was doubled\nby mistake with a single one.\n\nCiao,\nDscho\n"},{"id":"467716","messageId":"pull.1429.v2.git.1669058388327.gitgitgadget@gmail.com","threadId":"58830","inReplyTo":"pull.1429.git.1669037992587.gitgitgadget@gmail.com","subject":"[PATCH v2] config: introduce an Operating System-specific `includeIf` condition","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-11-21T19:19:48Z","receivedAt":"2022-11-21T19:19:58Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin \n\nIt is relatively common for users to maintain identical `~/.gitconfig`\nfiles across all of their setups, using the `includeIf` construct\nliberally to adjust the settings to the respective setup as needed.\n\nIn case of Operating System-specific adjustments, Git currently offers\nno support to the users and they typically use a work-around like this:\n\n\t[includeIf \"gitdir:/home/\"]\n\t\tpath = ~/.gitconfig-linux\n\t[includeIf \"gitdir:/Users/\"]\n\t\tpath = ~/.gitconfig-mac\n\t[includeIf \"gitdir:C:\"]\n\t\tpath = ~/.gitconfig-windows\n\nHowever, this is fragile, as it would not even allow to discern between\nOperating Systems that happen to host their home directories in\n`/home/`, such as Linux and the BSDs.\n\nLet's introduce a new condition: `os:` where `` is the\nsystem name, i.e. the output of `uname -s`.\n\nThis addresses https://github.com/git-for-windows/git/issues/4125\n\nSigned-off-by: Johannes Schindelin \n---\n config: introduce an Operating System-specific includeIf condition\n \n I was about to write up guidelines how to write this patch, but it\n turned out that it was much faster to write the patch instead.\n \n Changes since v1:\n \n * The documentation now avoids mentioning uname -s and clarifies what\n it means by offering examples.\n * Replaced a double space in the test case with a single one.\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-1429%2Fdscho%2Finclude-if-os-v2\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1429/dscho/include-if-os-v2\nPull-Request: https://github.com/gitgitgadget/git/pull/1429\n\nRange-diff vs v1:\n\n 1: a7eb4a9d438 ! 1: 45231533883 config: introduce an Operating System-specific `includeIf` condition\n @@ Documentation/config.txt: As for the naming of this keyword, it is for forwards\n \n +`os`::\n +\tThe data that follows this keyword is taken as the name of an\n -+\tOperating System; If it matches the output of `uname -s`, the\n -+\tinclude condition is met.\n ++\tOperating System, e.g. `Linux` or `Windows`; If it matches the\n ++\tcurrent Operating System, the include condition is met.\n +\n A few more notes on matching via `gitdir` and `gitdir/i`:\n \n @@ t/t1309-early-config.sh: test_expect_success 'onbranch config outside of git rep\n +\t\tuname_s=\"$(uname -s)\"\n +\tfi &&\n +\ttest_config \"includeIf.os:not-$uname_s.path\" xyz &&\n -+\ttest 0 = \"$(git config x.y)\" &&\n ++\ttest 0 = \"$(git config x.y)\" &&\n +\ttest_config \"includeIf.os:$uname_s.path\" xyz &&\n +\ttest z = \"$(git config x.y)\"\n +'\n\n\n Documentation/config.txt | 5 +++++\n config.c | 11 +++++++++++\n t/t1309-early-config.sh | 16 ++++++++++++++++\n 3 files changed, 32 insertions(+)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex e376d547ce0..b90bcd8ecfe 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -186,6 +186,11 @@ As for the naming of this keyword, it is for forwards compatibiliy with\n a naming scheme that supports more variable-based include conditions,\n but currently Git only supports the exact keyword described above.\n \n+`os`::\n+\tThe data that follows this keyword is taken as the name of an\n+\tOperating System, e.g. `Linux` or `Windows`; If it matches the\n+\tcurrent Operating System, the include condition is met.\n+\n A few more notes on matching via `gitdir` and `gitdir/i`:\n \n * Symlinks in `$GIT_DIR` are not resolved before matching.\ndiff --git a/config.c b/config.c\nindex 9b0e9c93285..9ab311ae99b 100644\n--- a/config.c\n+++ b/config.c\n@@ -394,6 +394,15 @@ static int include_by_remote_url(struct config_include_data *inc,\n \t\t\t\t\t inc->remote_urls);\n }\n \n+static int include_by_os(const char *cond, size_t cond_len)\n+{\n+\tstruct utsname uname_info;\n+\n+\treturn !uname(&uname_info) &&\n+\t\t!strncasecmp(uname_info.sysname, cond, cond_len) &&\n+\t\t!uname_info.sysname[cond_len];\n+}\n+\n static int include_condition_is_true(struct config_include_data *inc,\n \t\t\t\t const char *cond, size_t cond_len)\n {\n@@ -408,6 +417,8 @@ static int include_condition_is_true(struct config_include_data *inc,\n \telse if (skip_prefix_mem(cond, cond_len, \"hasconfig:remote.*.url:\", &cond,\n \t\t\t\t &cond_len))\n \t\treturn include_by_remote_url(inc, cond, cond_len);\n+\telse if (skip_prefix_mem(cond, cond_len, \"os:\", &cond, &cond_len))\n+\t\treturn include_by_os(cond, cond_len);\n \n \t/* unknown conditionals are always false */\n \treturn 0;\ndiff --git a/t/t1309-early-config.sh b/t/t1309-early-config.sh\nindex 537435b90ae..b36afe1a528 100755\n--- a/t/t1309-early-config.sh\n+++ b/t/t1309-early-config.sh\n@@ -100,4 +100,20 @@ test_expect_success 'onbranch config outside of git repo' '\n \tnongit git help\n '\n \n+test_expect_success '[includeIf \"os:...\"]' '\n+\ttest_config x.y 0 &&\n+\techo \"[x] y = z\" >.git/xyz &&\n+\n+\tif test_have_prereq MINGW\n+\tthen\n+\t\tuname_s=Windows\n+\telse\n+\t\tuname_s=\"$(uname -s)\"\n+\tfi &&\n+\ttest_config \"includeIf.os:not-$uname_s.path\" xyz &&\n+\ttest 0 = \"$(git config x.y)\" &&\n+\ttest_config \"includeIf.os:$uname_s.path\" xyz &&\n+\ttest z = \"$(git config x.y)\"\n+'\n+\n test_done\n\nbase-commit: e4a4b31577c7419497ac30cebe30d755b97752c5\n-- \ngitgitgadget\n"},{"id":"467726","messageId":"Y3wKe7aO7I7bpmLm@coredump.intra.peff.net","threadId":"58830","inReplyTo":"pull.1429.v2.git.1669058388327.gitgitgadget@gmail.com","subject":"Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2022-11-21T23:32:11Z","receivedAt":"2022-11-21T23:32:15Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 21, 2022 at 07:19:48PM +0000, Johannes Schindelin via GitGitGadget wrote:\n\n> It is relatively common for users to maintain identical `~/.gitconfig`\n> files across all of their setups, using the `includeIf` construct\n> liberally to adjust the settings to the respective setup as needed.\n\nThis seems like a reasonable thing to have in general, but I wonder if\nyou have an example of how people use this. Mostly I am wondering:\n\n - is it sometimes a misuse, where users _think_ that the OS is\n correlated with some feature of Git. And they would be better off\n with some flag like \"does the current platform support fsmonitor\".\n\n - for cases where it really is \"uname -s\" the best differentiator? Or\n would they commonly want to lump FreeBSD and Linux into the same\n category, or to tell the difference between Debian versus Fedora?\n\n-Peff\n"},{"id":"467730","messageId":"xmqqwn7nua88.fsf@gitster.g","threadId":"58830","inReplyTo":"pull.1429.git.1669037992587.gitgitgadget@gmail.com","subject":"Re: [PATCH] config: introduce an Operating System-specific `includeIf` condition","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-11-22T00:03:03Z","receivedAt":"2022-11-22T00:03:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Johannes Schindelin via GitGitGadget\" \nwrites:\n\n> From: Johannes Schindelin \n>\n> It is relatively common for users to maintain identical `~/.gitconfig`\n> files across all of their setups, using the `includeIf` construct\n> liberally to adjust the settings to the respective setup as needed.\n>\n> In case of Operating System-specific adjustments, Git currently offers\n> no support to the users and they typically use a work-around like this:\n>\n> \t[includeIf \"gitdir:/home/\"]\n> \t\tpath = ~/.gitconfig-linux\n> \t[includeIf \"gitdir:/Users/\"]\n> \t\tpath = ~/.gitconfig-mac\n> \t[includeIf \"gitdir:C:\"]\n> \t\tpath = ~/.gitconfig-windows\n>\n> However, this is fragile, as it would not even allow to discern between\n> Operating Systems that happen to host their home directories in\n> `/home/`, such as Linux and the BSDs.\n>\n> Let's introduce a new condition: `os:` where `` is the\n> system name, i.e. the output of `uname -s`.\n\nAs I am not confident enough that we made the best choice that would\nlast forever with the initial attempt when we picked \"uname -s\" as\nthe way to switch on \"OS\", I wouldn't call it \"OS\". Perhaps\n\n\t[includeIf \"uname-s:Linux\"] path = ...\n\nwould be what I would pick. Other than that, the feature makes\nquite a lot of sense.\n\n"},{"id":"467761","messageId":"221122.864juraxl2.gmgdl@evledraar.gmail.com","threadId":"58830","inReplyTo":"pull.1429.v2.git.1669058388327.gitgitgadget@gmail.com","subject":"Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-11-22T14:01:24Z","receivedAt":"2022-11-22T14:11:37Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Nov 21 2022, Johannes Schindelin via GitGitGadget wrote:\n\n> From: Johannes Schindelin \n>\n> +`os`::\n> +\tThe data that follows this keyword is taken as the name of an\n> +\tOperating System, e.g. `Linux` or `Windows`; If it matches the\n> +\tcurrent Operating System, the include condition is met.\n> +\n> A few more notes on matching via `gitdir` and `gitdir/i`:\n\nThe reste of the \"includeif\" use glob matching and \"/i\" for icase. IOW\nthis is how this new feature would fit in:\n\t\n\t|--------+--------+----------+----------+------------------+----|\n\t| | gitdir | gitdir/i | onbranch | hasconfig:remote | os |\n\t|--------+--------+----------+----------+------------------+----|\n\t| icase? | N | Y | N | N | Y |\n\t| glob? | Y | Y | Y | Y | N |\n\t| path? | Y | Y | Y | Y | N |\n\t|--------+--------+----------+----------+------------------+----|\n\nI think at least flipping that \"glob\" to \"Y\" so you could match e.g.\n\"*BSD\" would be useful, and easier to explain in context, rather than\nwhy the rest use wildmatch() and this doesn't.\n\nFor matching the uname the case doesn't really matter, but for\nconsistency of the interface I think making it case-sensitive or adding\nan \"os/i\" would make sense. I.e. let's consistently use \"/i\" if & when\nsomething's case-insensitive.\n\n> +test_expect_success '[includeIf \"os:...\"]' '\n> +\ttest_config x.y 0 &&\n> +\techo \"[x] y = z\" >.git/xyz &&\n> +\n> +\tif test_have_prereq MINGW\n> +\tthen\n> +\t\tuname_s=Windows\n> +\telse\n> +\t\tuname_s=\"$(uname -s)\"\n> +\tfi &&\n> +\ttest_config \"includeIf.os:not-$uname_s.path\" xyz &&\n> +\ttest 0 = \"$(git config x.y)\" &&\n> +\ttest_config \"includeIf.os:$uname_s.path\" xyz &&\n> +\ttest z = \"$(git config x.y)\"\n> +'\n\nAs I pointed out in the v1, this still:\n\n * Hides segfaults in \"git config\", let's check the exit code.\n * Doesn't test the \"icase\" semantics you're introducing. Let's do that\n if it's intentional.\n"},{"id":"467767","messageId":"9c0ecaff-3d66-2b83-eb78-64632d1fcddd@dunelm.org.uk","threadId":"58830","inReplyTo":"221122.864juraxl2.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2022-11-22T14:31:52Z","receivedAt":"2022-11-22T14:33:10Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 22/11/2022 14:01, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Mon, Nov 21 2022, Johannes Schindelin via GitGitGadget wrote:\n> \n>> From: Johannes Schindelin \n>>\n>> +`os`::\n>> +\tThe data that follows this keyword is taken as the name of an\n>> +\tOperating System, e.g. `Linux` or `Windows`; If it matches the\n>> +\tcurrent Operating System, the include condition is met.\n>> +\n>> A few more notes on matching via `gitdir` and `gitdir/i`:\n> \n> The reste of the \"includeif\" use glob matching and \"/i\" for icase. IOW\n> this is how this new feature would fit in:\n> \t\n> \t|--------+--------+----------+----------+------------------+----|\n> \t| | gitdir | gitdir/i | onbranch | hasconfig:remote | os |\n> \t|--------+--------+----------+----------+------------------+----|\n> \t| icase? | N | Y | N | N | Y |\n> \t| glob? | Y | Y | Y | Y | N |\n> \t| path? | Y | Y | Y | Y | N |\n> \t|--------+--------+----------+----------+------------------+----|\n> \n> I think at least flipping that \"glob\" to \"Y\" so you could match e.g.\n> \"*BSD\" would be useful, and easier to explain in context, rather than\n> why the rest use wildmatch() and this doesn't.\n\nGlobbing could be useful for the BSDs.\n\nOne other thing I thought of is will users know \"Darwin\" means MacOS?\n\n> For matching the uname the case doesn't really matter, but for\n> consistency of the interface I think making it case-sensitive or adding\n> an \"os/i\" would make sense. I.e. let's consistently use \"/i\" if & when\n> something's case-insensitive.\n\nAll the other items listed in your table such as branch names are case \nsensitive. The os name is not so it is of no benefit at all to the user \nto match it case sensitively. Let's consistently test case sensitive \nkeys cases sensitively and case insensitive keys case insensitively.\n\nBest Wishes\n\nPhillip\n\n>> +test_expect_success '[includeIf \"os:...\"]' '\n>> +\ttest_config x.y 0 &&\n>> +\techo \"[x] y = z\" >.git/xyz &&\n>> +\n>> +\tif test_have_prereq MINGW\n>> +\tthen\n>> +\t\tuname_s=Windows\n>> +\telse\n>> +\t\tuname_s=\"$(uname -s)\"\n>> +\tfi &&\n>> +\ttest_config \"includeIf.os:not-$uname_s.path\" xyz &&\n>> +\ttest 0 = \"$(git config x.y)\" &&\n>> +\ttest_config \"includeIf.os:$uname_s.path\" xyz &&\n>> +\ttest z = \"$(git config x.y)\"\n>> +'\n> \n> As I pointed out in the v1, this still:\n> \n> * Hides segfaults in \"git config\", let's check the exit code.\n> * Doesn't test the \"icase\" semantics you're introducing. Let's do that\n> if it's intentional.\n"},{"id":"467795","messageId":"26daec59-2923-39f1-3699-c28c13234241@gmail.com","threadId":"58830","inReplyTo":"pull.1429.v2.git.1669058388327.gitgitgadget@gmail.com","subject":"Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2022-11-22T18:40:07Z","receivedAt":"2022-11-22T18:40:13Z","isPatch":true,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Dscho,\n\nLe 2022-11-21 à 14:19, Johannes Schindelin via GitGitGadget a écrit :\n> From: Johannes Schindelin \n> \n> It is relatively common for users to maintain identical `~/.gitconfig`\n> files across all of their setups, using the `includeIf` construct\n> liberally to adjust the settings to the respective setup as needed.\n> \n> In case of Operating System-specific adjustments, \n\nHere, as well as in the commit title, the rest of the message, and the changes to \nthe doc in the patch, I would downcase \"operating system\". \nIt's a common word that I don't think should be capitalized (in contrast to\nproper OS names like Windows and Linux).\n\nCheers,\nPhilippe.\n"},{"id":"467834","messageId":"xmqqilj6plta.fsf@gitster.g","threadId":"58830","inReplyTo":"9c0ecaff-3d66-2b83-eb78-64632d1fcddd@dunelm.org.uk","subject":"Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-11-23T00:16:17Z","receivedAt":"2022-11-23T00:16:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood writes:\n\n> All the other items listed in your table such as branch names are case\n> sensitive. The os name is not so it is of no benefit at all to the\n\nYou keep saying that you consider the OS name is case insensitive,\nbut I doubt that is the case, not in the sense that MacOS and macOS\nare two different operating systems, but in the sense that OS\npublishers have a single preferred way to spell their ware (which is\nshown in \"uname -s\" output), and we should respect that.\n\n"},{"id":"467861","messageId":"969a4399-a6db-7c72-f96c-8bbe5f6208d4@iee.email","threadId":"58830","inReplyTo":"pull.1429.v2.git.1669058388327.gitgitgadget@gmail.com","subject":"Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2022-11-23T10:40:11Z","receivedAt":"2022-11-23T10:53:33Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Dscho,\n\nOn 21/11/2022 19:19, Johannes Schindelin via GitGitGadget wrote:\n> From: Johannes Schindelin \n>\n> It is relatively common for users to maintain identical `~/.gitconfig`\n> files across all of their setups, using the `includeIf` construct\n> liberally to adjust the settings to the respective setup as needed.\n>\n> In case of Operating System-specific adjustments, Git currently offers\n> no support to the users and they typically use a work-around like this:\n>\n> \t[includeIf \"gitdir:/home/\"]\n> \t\tpath = ~/.gitconfig-linux\n> \t[includeIf \"gitdir:/Users/\"]\n> \t\tpath = ~/.gitconfig-mac\n> \t[includeIf \"gitdir:C:\"]\n> \t\tpath = ~/.gitconfig-windows\n>\n> However, this is fragile, as it would not even allow to discern between\n> Operating Systems that happen to host their home directories in\n> `/home/`, such as Linux and the BSDs.\n>\n> Let's introduce a new condition: `os:` where `` is the\n> system name, i.e. the output of `uname -s`.\n\nThis `uname -s` doesn't work well on Git-for-Windows (GfW) / Windows\nbecause GfW has its own internal compatibility code to spoof the result.\nInternally GfW sets it to \"Windows\" (see\nhttps://github.com/git/git/blob/master/compat/mingw.c#L3084-L3095).\n\nIf I ask for `uname -s` on the GfW bash, for me it returns\n`MINGW64_NT-10.0-19045`, both on the normal GfW install, and the GfW-SDK.\n\nIf I (as dumb user) try the CMD window prompt it's\n    'uname' is not recognized as an internal or external command,\n    operable program or batch file.\n\nThe Windows PowerShell also doesn't recognise the uname command.\n\nMy WSL reports `Linux`, though I haven't played with that for a while\n(do all *nix variants report that?).\n\nThus we'll need some way of assisting the users in determining the\ninternal system name that their local Git will find. It maybe that the\nman page just needs to be explicit about using \"Windows\" for the\nGit-for-Windows implementation.\n\nOr less helpful, maybe a `git-uname` command to disambiguate any other\nsystems with a compat::uname() variant.\n\nOr just drop the mentions of \"\" in this commit message and\nrename it 'sysname' to match the field of the struct utsname?\n\n>\n> This addresses https://github.com/git-for-windows/git/issues/4125\n>\n> Signed-off-by: Johannes Schindelin \n> ---\n> config: introduce an Operating System-specific includeIf condition\n> \n> I was about to write up guidelines how to write this patch, but it\n> turned out that it was much faster to write the patch instead.\n> \n> Changes since v1:\n> \n> * The documentation now avoids mentioning uname -s and clarifies what\n> it means by offering examples.\n> * Replaced a double space in the test case with a single one.\n>\n> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1429%2Fdscho%2Finclude-if-os-v2\n> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1429/dscho/include-if-os-v2\n> Pull-Request: https://github.com/gitgitgadget/git/pull/1429\n>\n> Range-diff vs v1:\n>\n> 1: a7eb4a9d438 ! 1: 45231533883 config: introduce an Operating System-specific `includeIf` condition\n> @@ Documentation/config.txt: As for the naming of this keyword, it is for forwards\n> \n> +`os`::\n> +\tThe data that follows this keyword is taken as the name of an\n> -+\tOperating System; If it matches the output of `uname -s`, the\n> -+\tinclude condition is met.\n> ++\tOperating System, e.g. `Linux` or `Windows`; If it matches the\n> ++\tcurrent Operating System, the include condition is met.\n> +\n> A few more notes on matching via `gitdir` and `gitdir/i`:\n> \n> @@ t/t1309-early-config.sh: test_expect_success 'onbranch config outside of git rep\n> +\t\tuname_s=\"$(uname -s)\"\n> +\tfi &&\n> +\ttest_config \"includeIf.os:not-$uname_s.path\" xyz &&\n> -+\ttest 0 = \"$(git config x.y)\" &&\n> ++\ttest 0 = \"$(git config x.y)\" &&\n> +\ttest_config \"includeIf.os:$uname_s.path\" xyz &&\n> +\ttest z = \"$(git config x.y)\"\n> +'\n>\n>\n> Documentation/config.txt | 5 +++++\n> config.c | 11 +++++++++++\n> t/t1309-early-config.sh | 16 ++++++++++++++++\n> 3 files changed, 32 insertions(+)\n>\n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index e376d547ce0..b90bcd8ecfe 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -186,6 +186,11 @@ As for the naming of this keyword, it is for forwards compatibiliy with\n> a naming scheme that supports more variable-based include conditions,\n> but currently Git only supports the exact keyword described above.\n> \n> +`os`::\n> +\tThe data that follows this keyword is taken as the name of an\n> +\tOperating System, e.g. `Linux` or `Windows`; If it matches the\n> +\tcurrent Operating System\n\nIs 'matches' the appropriate way to indicate that we compare just the\ncharacters from the data string and ignore any trailing chars in the\nuname.sysname field?\n\n> , the include condition is met.\n> +\n> A few more notes on matching via `gitdir` and `gitdir/i`:\n> \n> * Symlinks in `$GIT_DIR` are not resolved before matching.\n> diff --git a/config.c b/config.c\n> index 9b0e9c93285..9ab311ae99b 100644\n> --- a/config.c\n> +++ b/config.c\n> @@ -394,6 +394,15 @@ static int include_by_remote_url(struct config_include_data *inc,\n> \t\t\t\t\t inc->remote_urls);\n> }\n> \n> +static int include_by_os(const char *cond, size_t cond_len)\n> +{\n> +\tstruct utsname uname_info;\n> +\n> +\treturn !uname(&uname_info) &&\n> +\t\t!strncasecmp(uname_info.sysname, cond, cond_len) &&\n> +\t\t!uname_info.sysname[cond_len];\n> +}\n> +\n> static int include_condition_is_true(struct config_include_data *inc,\n> \t\t\t\t const char *cond, size_t cond_len)\n> {\n> @@ -408,6 +417,8 @@ static int include_condition_is_true(struct config_include_data *inc,\n> \telse if (skip_prefix_mem(cond, cond_len, \"hasconfig:remote.*.url:\", &cond,\n> \t\t\t\t &cond_len))\n> \t\treturn include_by_remote_url(inc, cond, cond_len);\n> +\telse if (skip_prefix_mem(cond, cond_len, \"os:\", &cond, &cond_len))\n> +\t\treturn include_by_os(cond, cond_len);\n\n(as above) We compare only on the basis of the few/many characters in\nthe config file so, IIUC, we could use `Win`, or `Lin` as the os:\nstring. Should this be noted in the man text? I'm thinking of users who\nmay be confused by having to change Win10 to Windows, but are happy to\nshorten to `Win`.\n> \n> \t/* unknown conditionals are always false */\n> \treturn 0;\n> diff --git a/t/t1309-early-config.sh b/t/t1309-early-config.sh\n> index 537435b90ae..b36afe1a528 100755\n> --- a/t/t1309-early-config.sh\n> +++ b/t/t1309-early-config.sh\n> @@ -100,4 +100,20 @@ test_expect_success 'onbranch config outside of git repo' '\n> \tnongit git help\n> '\n> \n> +test_expect_success '[includeIf \"os:...\"]' '\n> +\ttest_config x.y 0 &&\n> +\techo \"[x] y = z\" >.git/xyz &&\n> +\n> +\tif test_have_prereq MINGW\n> +\tthen\n> +\t\tuname_s=Windows\n\nThis (correctly) copies/follows the compat code\n(https://github.com/git/git/blob/master/compat/mingw.c#L3088), but isn't\nwhat a GfW user sees if `uname-s` is run in their bash. Maybe change\nuname_s to sysname, as noted above.\n> +\telse\n> +\t\tuname_s=\"$(uname -s)\"\n> +\tfi &&\n> +\ttest_config \"includeIf.os:not-$uname_s.path\" xyz &&\n> +\ttest 0 = \"$(git config x.y)\" &&\n> +\ttest_config \"includeIf.os:$uname_s.path\" xyz &&\n> +\ttest z = \"$(git config x.y)\"\n> +'\n> +\n> test_done\n>\n> base-commit: e4a4b31577c7419497ac30cebe30d755b97752c5\n--\nPhilip\n"},{"id":"467862","messageId":"Y34KBTx+gQB13GRv@danh.dev","threadId":"58830","inReplyTo":"Y3wKe7aO7I7bpmLm@coredump.intra.peff.net","subject":"Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2022-11-23T11:54:45Z","receivedAt":"2022-11-23T11:54:52Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2022-11-21 18:32:11-0500, Jeff King wrote:\n> On Mon, Nov 21, 2022 at 07:19:48PM +0000, Johannes Schindelin via GitGitGadget wrote:\n> \n> > It is relatively common for users to maintain identical `~/.gitconfig`\n> > files across all of their setups, using the `includeIf` construct\n> > liberally to adjust the settings to the respective setup as needed.\n> \n> This seems like a reasonable thing to have in general, but I wonder if\n> you have an example of how people use this. Mostly I am wondering:\n> \n> - is it sometimes a misuse, where users _think_ that the OS is\n> correlated with some feature of Git. And they would be better off\n> with some flag like \"does the current platform support fsmonitor\".\n\nA possible use-case is setting credential.helper based on OS, let's say\nlibsecret on Linux, and osxkeychain on macOS. Of course, users can\nhave their own helper on specific OS.\n\n> \n> - for cases where it really is \"uname -s\" the best differentiator? Or\n> would they commonly want to lump FreeBSD and Linux into the same\n> category, or to tell the difference between Debian versus Fedora?\n> \n> -Peff\n\n-- \nDanh\n"},{"id":"467871","messageId":"a07b5cd7-7ada-7cdf-78cc-375ef21687b0@dunelm.org.uk","threadId":"58830","inReplyTo":"xmqqilj6plta.fsf@gitster.g","subject":"Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2022-11-23T15:07:41Z","receivedAt":"2022-11-23T15:07:51Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Junio\n\nWelcome back, I hope you enjoyed your time away from the list.\n\nOn 23/11/2022 00:16, Junio C Hamano wrote:\n> Phillip Wood writes:\n> \n>> All the other items listed in your table such as branch names are case\n>> sensitive. The os name is not so it is of no benefit at all to the\n> \n> You keep saying that you consider the OS name is case insensitive,\n> but I doubt that is the case, not in the sense that MacOS and macOS\n> are two different operating systems, but in the sense that OS\n> publishers have a single preferred way to spell their ware (which is\n> shown in \"uname -s\" output), and we should respect that.\n\nI can see that we would want to respect the preferred spelling in our \ndocumentation but it seems a bit mean to penalize users who write\n\n\t[IncludeIf \"os:windows\"]\n\nrather than\n\n\t[IncludeIf \"os:Windows\"]\n\nBest Wishes\n\nPhillip\n\n"},{"id":"467887","messageId":"xmqqk03lmdqc.fsf@gitster.g","threadId":"58830","inReplyTo":"a07b5cd7-7ada-7cdf-78cc-375ef21687b0@dunelm.org.uk","subject":"Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-11-23T23:51:23Z","receivedAt":"2022-11-23T23:51:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood writes:\n\n> I can see that we would want to respect the preferred spelling in our\n> documentation but it seems a bit mean to penalize users who write\n>\n> \t[IncludeIf \"os:windows\"]\n>\n> rather than\n>\n> \t[IncludeIf \"os:Windows\"]\n\nI do not think \"uname-s/i:windows\" is out of question. I am saying\nthat the default should be case sensitive for consistency with\nothers.\n\nAlso, as I said already, I do not think we should squat on a good\nname \"os\" with this \"uname -s\" feature that may not be a good\ndifferenciator for two OSes for some cases (e.g. telling Debian and\nFedora apart was a good example raised upthread already).\n"},{"id":"467893","messageId":"Y37BU6UA4plxNJCf@coredump.intra.peff.net","threadId":"58830","inReplyTo":"Y34KBTx+gQB13GRv@danh.dev","subject":"Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2022-11-24T00:56:51Z","receivedAt":"2022-11-24T00:57:05Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 23, 2022 at 06:54:45PM +0700, Đoàn Trần Công Danh wrote:\n\n> > This seems like a reasonable thing to have in general, but I wonder if\n> > you have an example of how people use this. Mostly I am wondering:\n> > \n> > - is it sometimes a misuse, where users _think_ that the OS is\n> > correlated with some feature of Git. And they would be better off\n> > with some flag like \"does the current platform support fsmonitor\".\n> \n> A possible use-case is setting credential.helper based on OS, let's say\n> libsecret on Linux, and osxkeychain on macOS. Of course, users can\n> have their own helper on specific OS.\n\nThanks, that's a very nice concrete example. I agree that's a pretty\nreasonable use of this feature, given the lack of other selection\nmechanisms. I do wonder if folks might run into annoyances when they\nwant to use libsecret on Linux _and_ FreeBSD or similar. But this\nfeature is definitely better than the status quo, and is not very much\ncode to implement or support.\n\n-Peff\n"},{"id":"467978","messageId":"xmqqk03jcwxz.fsf@gitster.g","threadId":"58830","inReplyTo":"969a4399-a6db-7c72-f96c-8bbe5f6208d4@iee.email","subject":"Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-11-25T07:31:04Z","receivedAt":"2022-11-25T07:31:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley writes:\n\n>> Let's introduce a new condition: `os:` where `` is the\n>> system name, i.e. the output of `uname -s`.\n>\n> This `uname -s` doesn't work well on Git-for-Windows (GfW) / Windows\n> because GfW has its own internal compatibility code to spoof the result.\n> ...\n> Or just drop the mentions of \"\" in this commit message and\n> rename it 'sysname' to match the field of the struct utsname?\n\nFWIW I do not mind \"sysname\". It is much better to say\n\n\t[includeIf \"sysname:Linux\"] path = ...\n\nthan \"os:Linux\", as \"sysname\" informs us the granularity used to\nidentify the system better than \"os\".\n\n\n"},{"id":"475499","messageId":"CABwTEiRz+-+Zdx3Ed7O09Ch8GoXH-SnmJyc-vFOdF-hk_uO-yA@mail.gmail.com","threadId":"58830","inReplyTo":"xmqqk03jcwxz.fsf@gitster.g","subject":"Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition","fromName":"Samuel Ferencik","fromEmail":"sferencik@gmail.com","sentAt":"2023-04-17T07:04:25Z","receivedAt":"2023-04-17T07:04:45Z","isPatch":true,"sender":{"key":"sferencik@gmail.com","avatar":null},"body":">>> Let's introduce a new condition: `os:` where `` is the\n>>> system name, i.e. the output of `uname -s`.\n\nThe discussion about https://github.com/gitgitgadget/git/pull/1429 seems to\nhave stalled on several points. I'll try to summarise; let's see if we can move\nforward.\n\n(I am the reporter of https://github.com/git-for-windows/git/issues/4125, which\nled to this PR. I am vested in making progress here.)\n\n1. name of the setting (`os` vs `uname-s` vs `sysname`)\n * dscho@ suggested `os`; Phillip and Philip suggested `uname-s` and\n `sysname`, respectively\n * I vote for `os`; I'm afraid perfect is the enemy of good here as\n * `man uname` says `-s` gives \"the name of the operating system\n implementation\"; no other `uname` switch comes closer to whatever\n concept \"OS\" represents\n * this is also correct on Windows (the \"Windows\" string) - see below\n * I find it extremely unlikely a future unforeseen git feature would have\n a better use for `includeIf os` (in parallel with `includeIf sysname`),\n i.e. I don't worry that we're squatting on a good name for a poor\n use-case\n2. casing (use of `/i`)\n * dscho@ implemented case-insensitive comparison but without test coverage,\n documentation, and it's inconsistent with the other `includeIf` options\n that support the `/i` switch.\n * I propose that we compare case-sensitively because\n * no user can reasonably complain about this if the documentation is\n clear; the OS names are definitive and stable and it's not a big deal\n getting the case right for \"Linux\"\n * without the case insensitivity being documented, the users who [discover\n the insensitivity and] rely on it are risking breakage; plus the git\n maintainers are exposing themselves to the effects of Hyrum's law\n (https://xkcd.com/1172) - it's a disservice for both sides\n * this still allows us to add support for `/i` later (should a use-case\n emerge)\n * it is consistent with the other settings\n * it requires less code (incl. tests) and shorter documentation\n3. handling Windows (MinGW, WSL)\n * As implemented currently, `includeIf \"os:Windows\"` would work in\n git-for-Windows. I think that's desirable, and no-one suggested otherwise.\n * In contrast, Philip points out `includeIf \"os:Linux\"` would be the way to\n match on WSL. Is that an issue? Do we want WSL to match \"os:Windows\" or\n \"os:WSL\"? As a Windows user, when I switch to WSL I do expect a \"proper\"\n Linux experience (unlike when I run \"Git bash\" on Windows, which is more\n like a port of utilities, but still Windows). I think this treating WLS as\n Linux is OK-ish, and we may get away with not discerning WSL. Thoughts?\n4. documentation (w.r.t. the details in 1. - 3.)\n * We should document all of 1. - 3. I'm happy to give it a go if we can\n reach consensus.\n * Specifically, the documentation should mention that the OS string equals\n \"Windows\" in Git-for-Windows, and `$(uname -s)` otherwise; it should list\n examples, incl. \"Linux\" and \"Darwin\"; it should mention the case\n sensitivity.\n5. tests (potential segfaults)\n * Johannes points out the tests hide segfaults. I haven't looked at this\n closely but hopefully Johannes's suggestion (\"use test_cmp or\n test_cmp_config\") is a clear enough pointer. I can try to fix this.\n6. what's the use-case?\n * As the reporter of https://github.com/git-for-windows/git/issues/4125,\n here are my use-cases, i.e. settings that I currently set conditionally\n per OS (using `includeIf gitdir`):\n * different `difftool.path`, `mergetool.path` per OS (e.g. paths\n containing `C:\\Program Files\\...\\...exe` vs Unix file paths)\n * different `merge.tool` per OS (I have a BeyondCompare license for Linux\n only)\n * different `core.autocrlf`: `true` on Windows, `input` otherwise\n * `core.whitespace` set to `cr-at-eol` on Windows\n * `core.editor` set to `gvim` on Windows\n * Note all of the use-cases above would cope with WSL reporting \"Linux\",\n except of `merge.tool`.\n\nI hope this revives the discussion; I know it's been a while but I would\nappreciate your input. If possible, please refer to the numbered points (1 - 6)\nfor clarity.\n\nI'm happy to iterate on dscho@'s PR if we can reach consensus.\n\n\nOn Fri, 14 Apr 2023 at 01:44, Junio C Hamano wrote:\n>\n> Philip Oakley writes:\n>\n> >> Let's introduce a new condition: `os:` where `` is the\n> >> system name, i.e. the output of `uname -s`.\n> >\n> > This `uname -s` doesn't work well on Git-for-Windows (GfW) / Windows\n> > because GfW has its own internal compatibility code to spoof the result.\n> > ...\n> > Or just drop the mentions of \"\" in this commit message and\n> > rename it 'sysname' to match the field of the struct utsname?\n>\n> FWIW I do not mind \"sysname\". It is much better to say\n>\n> [includeIf \"sysname:Linux\"] path = ...\n>\n> than \"os:Linux\", as \"sysname\" informs us the granularity used to\n> identify the system better than \"os\".\n>\n>\n>\n"},{"id":"475538","messageId":"xmqq7cuamjmu.fsf@gitster.g","threadId":"58830","inReplyTo":"CABwTEiRz+-+Zdx3Ed7O09Ch8GoXH-SnmJyc-vFOdF-hk_uO-yA@mail.gmail.com","subject":"Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-04-17T18:46:49Z","receivedAt":"2023-04-17T18:46:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Samuel Ferencik writes:\n\n>>>> Let's introduce a new condition: `os:` where `` is the\n>>>> system name, i.e. the output of `uname -s`.\n>\n> The discussion about https://github.com/gitgitgadget/git/pull/1429 seems to\n> have stalled on several points. I'll try to summarise; let's see if we can move\n> forward.\n>\n> (I am the reporter of https://github.com/git-for-windows/git/issues/4125, which\n> led to this PR. I am vested in making progress here.)\n>\n> 1. name of the setting (`os` vs `uname-s` vs `sysname`)\n\nI do not think it is a good idea to squat on too generic a name like\n'os', especially when there are multiple layers people will care\nabout. But I think the original thread discussed this to death, and\nI do not see a point bringing it up again as the first bullet point.\n\n> 2. casing (use of `/i`)\n\nMy preference is to do this case sensitively (in other words, start\nstupid) and if somebody wants to use \"/i\", add it later after the\ndust settles.\n\n> 3. handling Windows (MinGW, WSL)\n\nThis comes back to the reason why \"os\" is a horrible choice. Is WSL\na Windows? Is WSL a Linux? The same question can be asked for Cygwin.\n\nThe answer depends on which layer you care about. The underlying\nkernel and system may be Windows, and some characteristics of the\nunderlying system may seep through the abstraction, but these\nsystems aim to give user experience of something like GNU/Linux.\n\nAnd this is not limited to Windows. There may be similar issue for\nsystems like PacBSD. Is it a Linux? Is it a BSD?\n\n> 6. what's the use-case?\n\nI think that this is the most important question to ask, and from\nhere, we'd see how #3 above should be resolved (I suspect that you\nmay want to have at least two layers to allow WSL to be grouped\ntogether with MinGW and Cygwin at one level, and at the same time\nallow it to be grouped together with Ubuntu at a different level).\nAnd after we figure that out, we'll have a clear and intuitive\nanswer to #1.\n"},{"id":"475575","messageId":"643dfa919c8e1_19bb029491@chronos.notmuch","threadId":"58830","inReplyTo":"xmqq7cuamjmu.fsf@gitster.g","subject":"Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2023-04-18T02:04:01Z","receivedAt":"2023-04-18T02:04:07Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Samuel Ferencik writes:\n> \n> >>>> Let's introduce a new condition: `os:` where `` is the\n> >>>> system name, i.e. the output of `uname -s`.\n> >\n> > The discussion about https://github.com/gitgitgadget/git/pull/1429 seems to\n> > have stalled on several points. I'll try to summarise; let's see if we can move\n> > forward.\n> >\n> > (I am the reporter of https://github.com/git-for-windows/git/issues/4125, which\n> > led to this PR. I am vested in making progress here.)\n> >\n> > 1. name of the setting (`os` vs `uname-s` vs `sysname`)\n> \n> I do not think it is a good idea to squat on too generic a name like\n> 'os', especially when there are multiple layers people will care\n> about. But I think the original thread discussed this to death, and\n> I do not see a point bringing it up again as the first bullet point.\n\n\"platform\" is the term I've seen to be less OS-centric.\n\n-- \nFelipe Contreras\n"},{"id":"475683","messageId":"67a2d12c-6250-c4ee-dd26-fd8ecc71b8bc@gmx.de","threadId":"58830","inReplyTo":"xmqq7cuamjmu.fsf@gitster.g","subject":"Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2023-04-19T12:22:50Z","receivedAt":"2023-04-19T12:23:13Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Mon, 17 Apr 2023, Junio C Hamano wrote:\n\n> Samuel Ferencik writes:\n>\n> >>>> Let's introduce a new condition: `os:` where `` is the\n> >>>> system name, i.e. the output of `uname -s`.\n> >\n> > The discussion about https://github.com/gitgitgadget/git/pull/1429 seems to\n> > have stalled on several points. I'll try to summarise; let's see if we can move\n> > forward.\n> >\n> > (I am the reporter of https://github.com/git-for-windows/git/issues/4125, which\n> > led to this PR. I am vested in making progress here.)\n> >\n> > 1. name of the setting (`os` vs `uname-s` vs `sysname`)\n>\n> I do not think it is a good idea to squat on too generic a name like\n> 'os', especially when there are multiple layers people will care\n> about. But I think the original thread discussed this to death, and\n> I do not see a point bringing it up again as the first bullet point.\n\nGiven what you said about \"Operating System\", i.e. that both \"Ubuntu\" and\n\"Linux\" should be able to match at the same time, I kind of concur, but in\nthe other direction: rather than forcing the current patch series to use a\nless intuitive (i.e. user-unfriendlier) name than `os`, I would want to\nmodify the patch series so that it _can_ match \"Ubuntu\" and \"Linux\".\n\n> > 2. casing (use of `/i`)\n>\n> My preference is to do this case sensitively (in other words, start\n> stupid) and if somebody wants to use \"/i\", add it later after the\n> dust settles.\n\nI strongly disagree with this. This feature is meant for Git users, who I\nmust assume based on my experience would expect the value to be\ncase-insensitive. I.e. they would expect both `linux` and `Linux` to\nmatch. Let's not make this feature harder to use than necessary!\n\n> > 3. handling Windows (MinGW, WSL)\n>\n> This comes back to the reason why \"os\" is a horrible choice. Is WSL\n> a Windows? Is WSL a Linux? The same question can be asked for Cygwin.\n\nThese questions actually have pretty obvious answers, with the exception\nof WSL1 (which nobody should use anymore): WSL is a Linux, Cygwin is not\nan Operating System by itself but runs on Windows. But of course that's\nnot helpful to help configure Git specifically in a Cygwin setup.\n\n> The answer depends on which layer you care about.\n\nYes, this is the crucial bit.\n\n> The underlying kernel and system may be Windows, and some\n> characteristics of the underlying system may seep through the\n> abstraction, but these systems aim to give user experience of something\n> like GNU/Linux.\n>\n> And this is not limited to Windows. There may be similar issue for\n> systems like PacBSD. Is it a Linux? Is it a BSD?\n>\n> > 6. what's the use-case?\n>\n> I think that this is the most important question to ask, and from\n> here, we'd see how #3 above should be resolved (I suspect that you\n> may want to have at least two layers to allow WSL to be grouped\n> together with MinGW and Cygwin at one level, and at the same time\n> allow it to be grouped together with Ubuntu at a different level).\n> And after we figure that out, we'll have a clear and intuitive\n> answer to #1.\n\nThis is probably the most valuable feedback in this entire thread: What is\nthe problem we're trying to solve here?\n\nThe original report (which this patch tries to address) asks for a way to\nhave a user-wide (\"global\") Git configuration that can be shared across\nmachines and that allows for adapting to the various environments. The\nrationale is motivated well e.g. in\nhttps://medium.com/doing-things-right/platform-specific-gitconfigs-and-the-wonderful-includeif-7376cd44994d\nwhere platform-specific credential managers, editors, diff highlighters\nthat work only in certain setups, and work vs personal environments are\nmentioned.\n\nSo as long as Git offers ways to discern between the mentioned\nenvironments by including environment-specific configuration files, we\nsolve the problem.\n\nBonus points if we can do that without getting ever deeper into a pretty\ncontentious discussion about naming.\n\nThe strategy chosen in above-mentioned article uses the presence of\ncertain directories as tell-tales for the Operating System in which\nGit is called: Linux, macOS or Windows. Concretely, it suggests this:\n\n\t[includeIf \"gitdir:/Users\"]\n\t\tpath = ~/.gitconfig-macos\n\t[includeIf \"gitdir:C:\"]\n\t\tpath = ~/.gitconfig-windows\n\t[includeIf \"gitdir:/home\"]\n\t\tpath = ~/.gitconfig-linux\n\nNow, the presence of directories like `/home/` might work well to discern\nLinux from macOS, but this is not the correct way to identify Linux in\ngeneral (a `/home/` directory exists in many Unices, too). And it only\nworks when the _gitdir_ is in those directories, too. That's why I thought\nthat Git could do better.\n\nIn many cases, though, the presence of directories is probably \"good\nenough\" to address the need described in above-mentioned article.\n\nWhat triggered me to write this here patch was the report that those\n`/home/` and `/Users` paths in the Git config ran into the warning that\nGit for Windows no longer treats paths starting with a slash as relative\nto the runtime prefix. This warning was introduced when the `%(prefix)/`\nfeature was upstreamed, superseding Git for Windows' original handling of\npaths starting with a slash. The warning was introduced in November '21\n(virtually together with Git for Windows v2.34.0):\nhttps://github.com/git-for-windows/git/commit/28fdfd8a41836f49666c65e82d92de9befea2e69\n\nSo while I still think that something like `includeIf.os:` would\nmake for a better way to address the concern in question, I realize that\nthe path of least resistance is simply to drop the now-deprecated feature\nfrom Git for Windows (including the warning that was the reason for the\noriginal report): https://github.com/git-for-windows/git/pull/4389\n\nThis still leaves Git in the somewhat unsatisfying state where there is no\nbetter way to discern between Operating Systems than to work around by\ndetecting the presence of certain directories. But I do not see any viable\nway to reach consensus about the `includeIf.os:` patch, so I'll\nleave it at that.\n\nCiao,\nJohannes\n"},{"id":"475695","messageId":"CAPx1GvcsxFbdUBZayzAU0U1MNMUN2NqaBLfZ6C1M=SykWQ_CHg@mail.gmail.com","threadId":"58830","inReplyTo":"67a2d12c-6250-c4ee-dd26-fd8ecc71b8bc@gmx.de","subject":"Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition","fromName":"Chris Torek","fromEmail":"chris.torek@gmail.com","sentAt":"2023-04-19T14:26:42Z","receivedAt":"2023-04-19T14:27:37Z","isPatch":true,"sender":{"key":"chris.torek@gmail.com","avatar":"https://avatars.githubusercontent.com/u/16826774?v=4"},"body":"Note: I'm going to mix two things here (maybe not the best idea)\nand change the order.\n\nOn Wed, Apr 19, 2023 at 5:28 AM Johannes Schindelin\n wrote:\n\n> This is probably the most valuable feedback in this entire thread: What is\n> the problem we're trying to solve here?\n>\n> The original report (which this patch tries to address) asks for a way to\n> have a user-wide (\"global\") Git configuration that can be shared across\n> machines and that allows for adapting to the various environments. The\n> rationale is motivated well e.g. in\n> https://medium.com/doing-things-right/platform-specific-gitconfigs-and-the-wonderful-includeif-7376cd44994d\n> where platform-specific credential managers, editors, diff highlighters\n> that work only in certain setups, and work vs personal environments are\n> mentioned.\n\nWhy not allow use of environment variables? Perhaps a simple:\n\ngit config include.env.USER_VAR\n\nand/or:\n\ngit config include.ifexists.env.DIR\n\n(feel free to invent better names!) or similar. The user can then\n\nexport DIR=whatever\n\nin some outside-of-Git setup.\n\nOn a separate note:\n\n> ... This feature is meant for Git users, who I\n> must assume based on my experience would expect the value to be\n> case-insensitive. I.e. they would expect both `linux` and `Linux` to\n> match.\n\nI'm not at all sure about this: we already see a lot of confusion\nfrom people who don't understand why, if Git is case-sensitive\nabout branch names (which it is), Git isn't case-sensitive about\nbranch names *sometimes* on Windows and macOS.\n\n(In any case, using an env var sidesteps this question.)\n\nChris\n"},{"id":"475696","messageId":"CABwTEiSd1_WB_BXpT9BqkO3+rb2+FaZ7fFhGLo=CW=feKG2gUw@mail.gmail.com","threadId":"58830","inReplyTo":"CAPx1GvcsxFbdUBZayzAU0U1MNMUN2NqaBLfZ6C1M=SykWQ_CHg@mail.gmail.com","subject":"Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition","fromName":"Samuel Ferencik","fromEmail":"sferencik@gmail.com","sentAt":"2023-04-19T14:32:06Z","receivedAt":"2023-04-19T14:32:28Z","isPatch":true,"sender":{"key":"sferencik@gmail.com","avatar":null},"body":"[resending my previous response, which I had sent only to the PR, not the\nmailing list; composed before dscho@'s last email]\n\n> > 2. casing (use of `/i`)\n>\n> My preference is to do this case sensitively (in other words, start\n> stupid) and if somebody wants to use \"/i\", add it later after the\n> dust settles.\n\nFantastic.\n\n> > 6. what's the use-case?\n\n> > * Note all of the use-cases above would cope with WSL reporting \"Linux\",\n> > except of `merge.tool`.\n>\n> I think that this is the most important question to ask, and from\n> here, we'd see how #3 above should be resolved (I suspect that you\n> may want to have at least two layers to allow WSL to be grouped\n> together with MinGW and Cygwin at one level, and at the same time\n> allow it to be grouped together with Ubuntu at a different level).\n\nActually, I take that back: I can install the Linux version of BeyondCompare\ninto WSL, use my license, and I'm fine with WSL reporting that it's Linux.\n(This is just to correct my previous claim. More below.)\n\n> > 3. handling Windows (MinGW, WSL)\n>\n> The answer depends on which layer you care about. The underlying\n> kernel and system may be Windows, and some characteristics of the\n> underlying system may seep through the abstraction, but these\n> systems aim to give user experience of something like GNU/Linux.\n\nFair point. I think we only care about the top-most layer (the one nearest to\nthe user).\n\nThe \"seeping through\" aspect means things often aren't clear-cut, but I also\nthink we can make practical decisions. The closer the top layer approximates an\nOS, the more we can say it *is* that OS without compromising correctness. For\nexample, a Linux container on Windows should report (uname) it's a Linux, and\n`includeIf` should go by this. So should WSL2, I think, because it provides a\nLinux kernel. Maybe there is a use-case for git config (`includeIf`) to behave\ndifferently in WSL because the host OS is Windows, but I'm not aware of such a\nuse-case. In contrast, \"Git bash\" and Cygwin report something other than \"Linux\"\n(`MINGW64_NT-`, `CYGWIN_NT-`) because they are not Linuxes,\nand that's also fine. Interestingly, though, they don't report the host OS\n(Windows) either.\n\nSo I propose that we limit ourselves to the top-most layer. Can we come up with\na name (`os` or another) that would capture this concept?\n\n- Felipe proposed `platform`. I'm afraid this may be confused with the hardware\n platform (as reported by `uname -m`).\n- Phillip proposed `uname-s`. It's self-documenting in a way, but it's also\n wrong on Windows and describes the tool rather than the concept.\n- Philip proposed `sysname`. It's slightly better but still very much a pointer\n to `utsname.sysname`.\n- dscho@ proposed `os`. I like it for its obviousness. The issues with the name\n are marginal (not bigger than with any other name) and can be sufficiently\n addressed by good documentation.\n\nIf we can agree on the name, I can help fix up the documentation, the tests, and\nremove the case insensitivity. Thoughts?\n"},{"id":"475698","messageId":"009c01d972d2$b2bd7680$18386380$@nexbridge.com","threadId":"58830","inReplyTo":"67a2d12c-6250-c4ee-dd26-fd8ecc71b8bc@gmx.de","subject":"RE: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2023-04-19T15:21:58Z","receivedAt":"2023-04-19T15:23:57Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Wednesday, April 19, 2023 8:23 AM, Johannes Schindelin wrote:\n>On Mon, 17 Apr 2023, Junio C Hamano wrote:\n>\n>> Samuel Ferencik writes:\n>>\n>> >>>> Let's introduce a new condition: `os:` where ``\n>> >>>> is the system name, i.e. the output of `uname -s`.\n>> >\n>> > The discussion about https://github.com/gitgitgadget/git/pull/1429\n>> > seems to have stalled on several points. I'll try to summarise;\n>> > let's see if we can move forward.\n>> >\n>> > (I am the reporter of\n>> > https://github.com/git-for-windows/git/issues/4125, which led to\n>> > this PR. I am vested in making progress here.)\n>> >\n>> > 1. name of the setting (`os` vs `uname-s` vs `sysname`)\n>>\n>> I do not think it is a good idea to squat on too generic a name like\n>> 'os', especially when there are multiple layers people will care\n>> about. But I think the original thread discussed this to death, and I\n>> do not see a point bringing it up again as the first bullet point.\n>\n>Given what you said about \"Operating System\", i.e. that both \"Ubuntu\" and\n\"Linux\"\n>should be able to match at the same time, I kind of concur, but in the\nother direction:\n>rather than forcing the current patch series to use a less intuitive (i.e.\nuser-\n>unfriendlier) name than `os`, I would want to modify the patch series so\nthat it _can_\n>match \"Ubuntu\" and \"Linux\".\n>\n>> > 2. casing (use of `/i`)\n>>\n>> My preference is to do this case sensitively (in other words, start\n>> stupid) and if somebody wants to use \"/i\", add it later after the dust\n>> settles.\n>\n>I strongly disagree with this. This feature is meant for Git users, who I\nmust assume\n>based on my experience would expect the value to be case-insensitive. I.e.\nthey\n>would expect both `linux` and `Linux` to match. Let's not make this feature\nharder to\n>use than necessary!\n>\n>> > 3. handling Windows (MinGW, WSL)\n>>\n>> This comes back to the reason why \"os\" is a horrible choice. Is WSL a\n>> Windows? Is WSL a Linux? The same question can be asked for Cygwin.\n>\n>These questions actually have pretty obvious answers, with the exception of\nWSL1\n>(which nobody should use anymore): WSL is a Linux, Cygwin is not an\nOperating\n>System by itself but runs on Windows. But of course that's not helpful to\nhelp\n>configure Git specifically in a Cygwin setup.\n>\n>> The answer depends on which layer you care about.\n>\n>Yes, this is the crucial bit.\n>\n>> The underlying kernel and system may be Windows, and some\n>> characteristics of the underlying system may seep through the\n>> abstraction, but these systems aim to give user experience of\n>> something like GNU/Linux.\n>>\n>> And this is not limited to Windows. There may be similar issue for\n>> systems like PacBSD. Is it a Linux? Is it a BSD?\n>>\n>> > 6. what's the use-case?\n>>\n>> I think that this is the most important question to ask, and from\n>> here, we'd see how #3 above should be resolved (I suspect that you may\n>> want to have at least two layers to allow WSL to be grouped together\n>> with MinGW and Cygwin at one level, and at the same time allow it to\n>> be grouped together with Ubuntu at a different level).\n>> And after we figure that out, we'll have a clear and intuitive answer\n>> to #1.\n>\n>This is probably the most valuable feedback in this entire thread: What is\nthe problem\n>we're trying to solve here?\n>\n>The original report (which this patch tries to address) asks for a way to\nhave a user-\n>wide (\"global\") Git configuration that can be shared across machines and\nthat allows\n>for adapting to the various environments. The rationale is motivated well\ne.g. in\n>https://medium.com/doing-things-right/platform-specific-gitconfigs-and-the-\n>wonderful-includeif-7376cd44994d\n>where platform-specific credential managers, editors, diff highlighters\nthat work only\n>in certain setups, and work vs personal environments are mentioned.\n>\n>So as long as Git offers ways to discern between the mentioned environments\nby\n>including environment-specific configuration files, we solve the problem.\n\nI would suggest using match of uname arguments. But there are variants. The\nOS release should also be included here as something like NONSTOP_KERNEL is\nnot a sufficient answer. We should have at the very least, or encode the\nincludeif string accordingly:\n\nuname -r = the release n (e.g., J06)\nuname -n = the node name (e.g., hpitug)\nuname -s = the OS (e.g., NONSTOP_KERNEL\n\nWe use these in config.mak.uname (except for -n).\n\nRegards,\nRandall\n\n"},{"id":"475703","messageId":"xmqq354vama6.fsf@gitster.g","threadId":"58830","inReplyTo":"67a2d12c-6250-c4ee-dd26-fd8ecc71b8bc@gmx.de","subject":"Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-04-19T16:07:13Z","receivedAt":"2023-04-19T16:07:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> > 2. casing (use of `/i`)\n>>\n>> My preference is to do this case sensitively (in other words, start\n>> stupid) and if somebody wants to use \"/i\", add it later after the\n>> dust settles.\n>\n> I strongly disagree with this. This feature is meant for Git users, who I\n> must assume based on my experience would expect the value to be\n> case-insensitive. I.e. they would expect both `linux` and `Linux` to\n> match. Let's not make this feature harder to use than necessary!\n\n[jc: Read below with 'os' replaced with 'uname-s' or any of your\nfavorite. This message does not take any position on that part of\nthe discussion.]\n\nI am OK with the above position, if we make sure that all other\nincludeIf conditions are compared case insensitively, and if we make\nsure there is no existing \"/i\" includeIf conditions. Then those who\nwant to differentiate can later add \"/casesensitive\" option.\n\nBut I do not want to see a system where some of the conditions are\ncompared case insensitively while some other conditions are compared\ncase sensitively. The end-users will then be forced to remember\n\"the condition 'os' can be spelled in any case permutation, but the\ncondition 'xyzzy' needs to be spelled in the right case\". It would\nnot be obvious to end users when they need to use \"/i\" variant in\nsuch a system.\n\nUnlike 'gitdir' whose value is arbitrarily chosen by the users and\nthe projects (where folks use both FooBar and foobar and want them\nto mean different things), the vocabulary of \"os\" is limited and I\nagree with you that it is very likely for any user to expect that\nany case permutations of \"linux\" would mean the same thing. But\nspelling \"windows\" and have it match even when the official name of\nthe system may be \"Windows\" should be the choice made by the end\nuser, and the \"/i\" suffix in \"os/i\" is a way for them to express it.\n\nYou might be able to talk me into adding only \"os/i\" added without\nadding \"os\", though. I do not see much point in doing so, other\nthan that we can say \"we do not take any position on what case\npermutation is the right and official way to spell the name of each\nsystem\".\n\nThanks.\n\n\n\n"},{"id":"475704","messageId":"xmqqy1mn97e7.fsf@gitster.g","threadId":"58830","inReplyTo":"67a2d12c-6250-c4ee-dd26-fd8ecc71b8bc@gmx.de","subject":"Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-04-19T16:14:08Z","receivedAt":"2023-04-19T16:14:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> The original report (which this patch tries to address) asks for a way to\n> have a user-wide (\"global\") Git configuration that can be shared across\n> machines and that allows for adapting to the various environments.\n> ...\n> So as long as Git offers ways to discern between the mentioned\n> environments by including environment-specific configuration files, we\n> solve the problem.\n\nPerhaps \n\n [includeIf \"ifExists:/path/to/foo-credential-manager.exe\"]\n\tpath = /path/to/config/needed/for/using/foo-credential-manager\n\nis being called for? \"os\" being \"LiNuX\" does not tell much about\nthe environment differences the end users would care about, like\nwhat desktop environment is in use, which leads to the availability\nand default choice of GUI tools, to help them auto-configure.\n\n"}]}