Re: [PATCH 0/5] [RFC] Make 'git config list --type=' parse and filter types

From: Derrick Stolee <stolee@gmail.com>
Date: Feb 10, 2026, 18:18 UTC
Message-ID: <ccde188e-267c-479c-a012-a33027b2df63@gmail.com>
In-Reply-To: <xmqqldh119e7.fsf@gitster.g>

On 2/9/2026 11:59 PM, Junio C Hamano wrote:

Show 25 quoted lines

> "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:...
>> This boils down to the fact that the iterator function show_all_config()
>> doesn't call format_config(), which includes the type-parsing code.
>>
>> This wasn't super trivial to update:
>>
>>  1. format_config() uses git_config_parse_*() methods, which die() on a bad
>>     parse.
>>  2. The path parsing code didn't have a gentle version.
>>  3. The two paths ('git config list' and 'git config --list') needed to
>>     standardize their display options to work with format_config().
> 
> Thanks for dealing with them.  These are what I would have expected
> as part of the "inevitable consequence".
> 
>>  4. Finally, we need to filter out key-value pairs that don't match the
>>     given type.
> 
> This one, however, I need to see the actual code before commenting,
> as I do not think key-value pairs have inherent types.  The _only_
> special case where you can tell what type the thing is is the
> valueless true, which we can safely say is inherently boolean.
> Everything else is text string, sometimes interpreted as boolean,
> sometimes number, sometimes human-scaled number, sometimes path
> (with possible tilde expansion), etc.

This is the crux of this series. If the caller asks for a type, then I see a couple different ways to react:

 1. If the value fails to parse in that type, then don't list that
    result, allowing the caller to have confidence that every result
    is of the correct format.

 2. If the value fails to parse in that type, then list it in its
    base string. The caller would need to do extra parsing to check
    that the results match the correct format.

I chose option 1. It avoids showing results that would result in 'git config get --type=<X> <key>' to die().

I'd be interested to hear if there are reasons to go with option 2, or if there exists an alternative option that I don't see.

Reordering your message somewhat:

Show 10 quoted lines

> As there is no "inherent" type associated with each configuration
> variable (in other words, type of a particular configuration
> variable is something determined by the caller that wants the value
> of that variable), "git config list/get --type=auto" would not work,
> but it would not be too bad to allow "git config list --type=path"
> to treat everything as if it is a path and having to filter nonsense
> out of the result (like "core.bare = true/false" or even "core.bare"
> without value that means true, which may make the "*force*
> interpreting it as path" approach to barf), which is an inevitable
> consequence.

I agree that there is not inherent type, so the user can only specify the type that they are expecting. To me, this is a request to filter the results.

I don't think we'll have much success if we try to guess the type, such as trying to parse an int, then a bool, then a path.

Thanks, -Stolee