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

[Junio C Hamano <gitster@pobox.com>]

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

> @@ -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...