Re: [PATCH v2 1/2] config: add options to list only variable names

From: Junio C Hamano <gitster@pobox.com>
Date: May 28, 2015, 19:20 UTC
Message-ID: <xmqqbnh4h5k4.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1432816175-18988-2-git-send-email-szeder@ira.uka.de>

SZEDER Gábor <szeder@ira.uka.de> writes:

Show 6 quoted lines

> @@ -16,11 +16,12 @@ SYNOPSIS
>  'git config' [<file-option>] [type] [-z|--null] --get-all name [value_regex]
>  'git config' [<file-option>] [type] [-z|--null] --get-regexp name_regex [value_regex]
>  'git config' [<file-option>] [type] [-z|--null] --get-urlmatch name URL
> +'git config' [<file-option>] [-z|--null] --get-name-regexp name_regex
> ...

At first I wondered why --get-name-regexp is needed, as (purely from the syntactic level) it appeared at the first glance the existing '--get-regexp' without 'value_regex' may be sufficient, until I read this:

> +--get-name-regexp::
> +	Like --get-regexp, but shows only matching variable names, not its
> +	values.

which makes it clear why it is needed. The distinction is purely about the output, i.e. the values are omitted.

But then it makes me wonder why --get-name-regexp shouldn't optionally accept value_regex like --get-regexp does, allowing you to say "list the variables that match this pattern whose values match this other pattern". I know it may be a feature that is unnecessary for your purpose, but from a cursory look of the patch text, you do not seem to be doing anything different between get-regexp and get-name-regexp codepaths other than flipping omit_values bit on, so it could be that the feature is already supported but forgot to document it, perhaps?

The 'type' may also be shared between these two options, no? It would be logically consistent if you can say

	git config --bool --get-name-regexp '.*' 'no'

to find all configuration variables that are set to 'false' in different spellings like '0', 'false', 'no', etc. And I suspect that the code already supports that.

Tangentially related to the above issue, but

	git config --bool --get-regexp '.*' 'no'

seems to be broken from that point of view. Instead of ignoring a non-bool string valued variables, it seems to barf upon seeing the first such variable. Interestingly, --get-name-regexp does not share that breakage ;-)

Which we may want to fix, but not in the scope of this series.

Hint, hint...