diff options
author | Jeff King <peff@peff.net> | 2014-10-07 15:33:09 -0400 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2014-10-14 11:01:21 -0700 |
commit | f6c5a2968c103621adf6928a29e4895361eaa23b (patch) | |
tree | 60259098fe84c3a71ad16aea43d2dbfb38dd0ee3 /Documentation/RelNotes/1.7.7.2.txt | |
parent | 8852117a603c5ed5131233a80453db37c0958871 (diff) | |
download | git-f6c5a2968c103621adf6928a29e4895361eaa23b.tar.gz |
color_parse: do not mention variable name in error messagejn/parse-config-slot
Originally the color-parsing function was used only for
config variables. It made sense to pass the variable name so
that the die() message could be something like:
$ git -c color.branch.plain=bogus branch
fatal: bad color value 'bogus' for variable 'color.branch.plain'
These days we call it in other contexts, and the resulting
error messages are a little confusing:
$ git log --pretty='%C(bogus)'
fatal: bad color value 'bogus' for variable '--pretty format'
$ git config --get-color foo.bar bogus
fatal: bad color value 'bogus' for variable 'command line'
This patch teaches color_parse to complain only about the
value, and then return an error code. Config callers can
then propagate that up to the config parser, which mentions
the variable name. Other callers can provide a custom
message. After this patch these three cases now look like:
$ git -c color.branch.plain=bogus branch
error: invalid color value: bogus
fatal: unable to parse 'color.branch.plain' from command-line config
$ git log --pretty='%C(bogus)'
error: invalid color value: bogus
fatal: unable to parse --pretty format
$ git config --get-color foo.bar bogus
error: invalid color value: bogus
fatal: unable to parse default color value
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/RelNotes/1.7.7.2.txt')
0 files changed, 0 insertions, 0 deletions