Subject: Re: `git config get --type=path` results in segmentation fault on value starting with `:(optional)`

From: Jeff King <[email-masked]>
Date: Wed, 26 Nov 2025 10:13:49 -0500

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