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, Phillip Wood <phillip.wood123@gmail.com>,
	Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition
Date: Tue, 22 Nov 2022 14:31:52 +0000	[thread overview]
Message-ID: <9c0ecaff-3d66-2b83-eb78-64632d1fcddd@dunelm.org.uk> (raw)
In-Reply-To: <221122.864juraxl2.gmgdl@evledraar.gmail.com>

On 22/11/2022 14:01, Ævar Arnfjörð Bjarmason wrote:
> 
> On Mon, Nov 21 2022, Johannes Schindelin via GitGitGadget wrote:
> 
>> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>>
>> +`os`::
>> +	The data that follows this keyword is taken as the name of an
>> +	Operating System, e.g. `Linux` or `Windows`; If it matches the
>> +	current Operating System, the include condition is met.
>> +
>>   A few more notes on matching via `gitdir` and `gitdir/i`:
> 
> The reste of the "includeif" use glob matching and "/i" for icase. IOW
> this is how this new feature would fit in:
> 	
> 	|--------+--------+----------+----------+------------------+----|
> 	|        | gitdir | gitdir/i | onbranch | hasconfig:remote | os |
> 	|--------+--------+----------+----------+------------------+----|
> 	| icase? | N      | Y        | N        | N                | Y  |
> 	| glob?  | Y      | Y        | Y        | Y                | N  |
> 	| path?  | Y      | Y        | Y        | Y                | N  |
> 	|--------+--------+----------+----------+------------------+----|
> 
> I think at least flipping that "glob" to "Y" so you could match e.g.
> "*BSD" would be useful, and easier to explain in context, rather than
> why the rest use wildmatch() and this doesn't.

Globbing could be useful for the BSDs.

One other thing I thought of is will users know "Darwin" means MacOS?

> For matching the uname the case doesn't really matter, but for
> consistency of the interface I think making it case-sensitive or adding
> an "os/i" would make sense. I.e. let's consistently use "/i" if & when
> something's case-insensitive.

All the other items listed in your table such as branch names are case 
sensitive. The os name is not so it is of no benefit at all to the user 
to match it case sensitively. Let's consistently test case sensitive 
keys cases sensitively and case insensitive keys case insensitively.

Best Wishes

Phillip

>> +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 &&
>> +	test 0 = "$(git config x.y)" &&
>> +	test_config "includeIf.os:$uname_s.path" xyz &&
>> +	test z = "$(git config x.y)"
>> +'
> 
> As I pointed out in the v1, this still:
> 
>   * Hides segfaults in "git config", let's check the exit code.
>   * Doesn't test the "icase" semantics you're introducing. Let's do that
>     if it's intentional.

  reply	other threads:[~2022-11-22 14:34 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
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 [this message]
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=9c0ecaff-3d66-2b83-eb78-64632d1fcddd@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).