From: Jeff King <peff@peff•net>
To: Junio C Hamano <gitster@pobox•com>
Cc: Han Jiang <jhcarl0814@gmail•com>, Git Mailing List <git@vger•kernel.org>
Subject: Re: `git config get --type=path` results in segmentation fault on value starting with `:(optional)`
Date: Wed, 26 Nov 2025 10:13:49 -0500 [thread overview]
Message-ID: <20251126151349.GD4143292@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqqa50budxc.fsf@gitster.g>
On Mon, Nov 24, 2025 at 04:57:35PM -0800, Junio C Hamano wrote:
> Hmph, I tend to disagree; this was not driven by ease of
> implementation at all. Rather, :(optional) cannot be an attribute
> of a variable; it is an attribute of individual setting of a variable.
>
> For example, imagine that you want to say "the system wide fallback
> is in this file in /etc, but you can override it with a file in your
> home directory", and you want to say that only once in the system
> wide configuration file so that it applies to all users, without
> each end user having to specify that they do want to override it in
> their Git configuration file.
>
> You can write this in /etc/gitconfig
>
> [default]
> editorConfig = /etc/editorConfig
> editorConfig = ':(optional)~/.editorConfig'
>
> and ask what path default.editorConfig file is. As long as large
> enough user population agrees what the name of the file under their
> $HOME to control the behaviour, this would work better than telling
> them "you can override default.editorCondfig in your per-user
> configuration file", as it is one fewer thing to configure.
>
> And this is possible only if we consider that what the system
> pretends not to have seen is per :(optional) definition.
Yes, I agree that the code as-is opens up that workflow. But it forbids
the flipside, which is: "the sysadmin set up a path in /etc, but I do not
ever want to use that; I want to use my file if present, or nothing".
Now which is more likely, I don't know. I've never wanted to do either. ;)
The workflow I suggest would also perhaps be more elegant if there was a
way to "unset" a variable. We allow that in some cases for list-like
variables, with an empty entry to reset the list. But usually for
single-valued variables, we assume that last-one-wins is enough.
-Peff
prev parent reply other threads:[~2025-11-26 15:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-20 6:46 `git config get --type=path` results in segmentation fault on value starting with `:(optional)` Han Jiang
2025-11-20 7:50 ` Jeff King
2025-11-20 14:34 ` D. Ben Knoble
2025-11-20 16:46 ` Junio C Hamano
2025-11-25 0:28 ` Jeff King
2025-11-25 0:57 ` Junio C Hamano
2025-11-26 15:13 ` Jeff King [this message]
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=20251126151349.GD4143292@coredump.intra.peff.net \
--to=peff@peff$(echo .)net \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=jhcarl0814@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox