Re: BUG: 'error: invalid key: pager.show_ref' on 'git show_ref'

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 6, 2015, 19:44 UTC
Message-ID: <xmqqbnl6hljt.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20150206193313.GA4220@peff.net>

Jeff King <peff@peff.net> writes:

Show 12 quoted lines

> On Fri, Feb 06, 2015 at 01:45:28PM +0100, Andreas Krey wrote:
>
>>   $ git show_ref
>>   error: invalid key: pager.show_ref
>>   error: invalid key: alias.show_ref
>>   git: 'show_ref' is not a git command. See 'git --help'.
>> 
>> Apparently we need to squelch this message from
>> within git_config_get_* in this case?
> ...
> So it is not a new problem, but it is a bug that you
> cannot set pager config for such a command or alias.

Hmm, I think these are two separate issues.

 (1) you cannot define "alias.my_merge" because that is not a valid
     key.  We cannot add a new official subcommand "git c_m_d"
     because users cannot define "pager.c_m_d" for it for the same
     reason.

 (2) "git no-such-command" does not get these extraneous error
     messages, but "git no_such_command" does.

Solution to (1) would be to move to "alias.my_merge.command = ..." and "pager.c_m_d.enabled = true". But I do not think that would solve (1) until we transition and start ignoring alias.my_merge and pager.c_m_d, and I do not think of a way other than squelching the messages to solve (1) during the transition period.

Show 17 quoted lines

> I can think of a few possible paths forward:
>
>   1. Squelch the messages, and declare "show_ref" and friends
>      out-of-luck for pager config or aliases.
>
>   2. Relax the syntactic rules for config keys to allow more characters.
>      We cannot make this perfect (e.g., we cannot allow "." for reasons
>      of ambiguity), but I imagine we could cover most practical cases.
>
>      Note that we would need the matching loosening on the file-parsing
>      side.
>
>   3. Start phasing in pager.*.enabled (and I guess pager.*.command). We
>      would still do the lookup of pager.* for backwards compatibility,
>      but we would be careful to do so only when it is syntactically
>      valid. IOW, this looks like (1), except the path forward for
>      "show_ref" is to use the new, more robust, syntax.

I guess I ended up reaching the same conclusion; 3. with also "alias.*.command" as the longer-term goal.