From: Jeff King Date: Wed, 26 Nov 2025 15:13:49 GMT Subject: Re: `git config get --type=path` results in segmentation fault on value starting with `:(optional)` Message-ID: <20251126151349.GD4143292@coredump.intra.peff.net> In-Reply-To: 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