git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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