git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Phillip Wood <phillip.wood123@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"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 15:51:23 +0000	[thread overview]
Message-ID: <aa054864-203b-3c06-0706-6cc40310a830@dunelm.org.uk> (raw)
In-Reply-To: <221121.86pmdgbdwa.gmgdl@evledraar.gmail.com>

Hi Dscho and Ævar

On 21/11/2022 13:51, Ævar Arnfjörð Bjarmason wrote:
> 
> 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.

Yes, it looks like a really useful enhancement

>> +`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

Maybe add e.g. "Windows or Linux" after Operating System?

>> +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?

Why should we penalize users who write "linux" rather than "Linux"? 
Making the comparison case insensitive seems eminently sensible. File 
systems can be case sensitive so having the option to specify whether a 
match for "gitdir" is case sensitive or not makes sense there but not 
for the name of an operating system.

Best Wishes

Phillip

  reply	other threads:[~2022-11-21 15:51 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
2022-11-21 15:51   ` Phillip Wood [this message]
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=aa054864-203b-3c06-0706-6cc40310a830@dunelm.org.uk \
    --to=phillip.wood123@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=johannes.schindelin@gmx.de \
    --cc=phillip.wood@dunelm.org.uk \
    /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).