All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: "Samuel Ferencik" <sferencik@gmail.com>,
	"Philip Oakley" <philipoakley@iee.email>,
	"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>,
	git@vger.kernel.org, "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Phillip Wood" <phillip.wood123@gmail.com>
Subject: Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition
Date: Wed, 19 Apr 2023 09:07:13 -0700	[thread overview]
Message-ID: <xmqq354vama6.fsf@gitster.g> (raw)
In-Reply-To: <67a2d12c-6250-c4ee-dd26-fd8ecc71b8bc@gmx.de> (Johannes Schindelin's message of "Wed, 19 Apr 2023 14:22:50 +0200 (CEST)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> > 2. casing (use of `/i`)
>>
>> My preference is to do this case sensitively (in other words, start
>> stupid) and if somebody wants to use "/i", add it later after the
>> dust settles.
>
> I strongly disagree with this. This feature is meant for Git users, who I
> must assume based on my experience would expect the value to be
> case-insensitive. I.e. they would expect both `linux` and `Linux` to
> match. Let's not make this feature harder to use than necessary!

[jc: Read below with 'os' replaced with 'uname-s' or any of your
favorite. This message does not take any position on that part of
the discussion.]

I am OK with the above position, if we make sure that all other
includeIf conditions are compared case insensitively, and if we make
sure there is no existing "/i" includeIf conditions.  Then those who
want to differentiate can later add "/casesensitive" option.

But I do not want to see a system where some of the conditions are
compared case insensitively while some other conditions are compared
case sensitively.  The end-users will then be forced to remember
"the condition 'os' can be spelled in any case permutation, but the
condition 'xyzzy' needs to be spelled in the right case".  It would
not be obvious to end users when they need to use "/i" variant in
such a system.

Unlike 'gitdir' whose value is arbitrarily chosen by the users and
the projects (where folks use both FooBar and foobar and want them
to mean different things), the vocabulary of "os" is limited and I
agree with you that it is very likely for any user to expect that
any case permutations of "linux" would mean the same thing.  But
spelling "windows" and have it match even when the official name of
the system may be "Windows" should be the choice made by the end
user, and the "/i" suffix in "os/i" is a way for them to express it.

You might be able to talk me into adding only "os/i" added without
adding "os", though.  I do not see much point in doing so, other
than that we can say "we do not take any position on what case
permutation is the right and official way to spell the name of each
system".

Thanks.




  parent reply	other threads:[~2023-04-19 16:07 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
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 [this message]
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

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

  git send-email \
    --in-reply-to=xmqq354vama6.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=philipoakley@iee.email \
    --cc=phillip.wood123@gmail.com \
    --cc=sferencik@gmail.com \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.