From: Jeff King <peff@peff.net>
To: Andreas Krey <a.krey@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: BUG: 'error: invalid key: pager.show_ref' on 'git show_ref'
Date: Fri, 6 Feb 2015 14:33:13 -0500 [thread overview]
Message-ID: <20150206193313.GA4220@peff.net> (raw)
In-Reply-To: <20150206124528.GA18859@inner.h.apk.li>
On Fri, Feb 06, 2015 at 01:45:28PM +0100, Andreas Krey wrote:
> there seems to be a regression in the behaviour of 'git show_ref'
> (note the underscore). In v2.0.3-711-g586f414 it starts to say:
>
> $ ./git show_ref
> error: invalid key: pager.show_ref
> git: 'show_ref' is not a git command. See 'git --help'.
>
> and somewhere (probably two commits, judging the diffs)
> later that changes again to:
>
> $ 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?
This is highlighting the problem with "pager.*" that Junio mentioned
recently, which is that the keyname has arbitrary data, but
syntactically is limited to alnum and "-". This should have been:
pager.show_ref.enabled
from the beginning. But of course it was not. Even if we transition, we
would want to support pager.* for a while.
I don't think squelching the messages is quite the right approach. They
come from git_config_parse_key, which barfs on parsing the syntactically
invalid keyname. So not only are we complaining, but we are not actually
looking up the value. I don't think that's technically a regression in
586f414, though. The reader started to complain, but AFAICT git would
not agree to parse a file containing:
[pager]
show_ref = true
in the first place. So it is not a new problem, but it is a bug that you
cannot set pager config for such a command or alias.
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.
-Peff
next prev parent reply other threads:[~2015-02-06 19:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-06 12:45 BUG: 'error: invalid key: pager.show_ref' on 'git show_ref' Andreas Krey
2015-02-06 19:33 ` Jeff King [this message]
2015-02-06 19:44 ` Junio C Hamano
2015-02-06 20:39 ` Jeff King
2015-02-10 19:45 ` [PATCH] config: add show_err flag to git_config_parse_key() Tanay Abhra
2015-02-11 0:27 ` Jeff King
2015-02-11 18:47 ` Junio C Hamano
2015-02-16 7:58 ` [PATCH v2] add a flag to supress errors in git_config_parse_key() Tanay Abhra
2015-02-18 19:02 ` Jeff King
2015-02-07 0:03 ` BUG: 'error: invalid key: pager.show_ref' on 'git show_ref' Mikael Magnusson
2015-02-07 5:01 ` Jeff King
2015-02-06 20:14 ` Junio C Hamano
2015-02-06 20:37 ` Jeff King
2015-02-06 22:17 ` Junio C Hamano
2015-02-06 22:27 ` Junio C Hamano
2015-02-07 4:52 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150206193313.GA4220@peff.net \
--to=peff@peff.net \
--cc=a.krey@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).