aboutsummaryrefslogtreecommitdiff
path: root/revision.c
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2010-11-17 12:00:45 -0500
committerJunio C Hamano <gitster@pobox.com>2010-11-17 10:59:23 -0800
commitb2be2f6aeaa8f4af602679e5571d2e916a259d91 (patch)
tree51669e54d8186e8b7050dfd584134412c1fd5c3e /revision.c
parentf772c34ce09a49eb553240eb672bf0cc2dbcb10a (diff)
downloadgit-b2be2f6aeaa8f4af602679e5571d2e916a259d91.tar.gz
git-b2be2f6aeaa8f4af602679e5571d2e916a259d91.tar.xz
log.decorate: accept 0/1 bool values
We explicitly document "0" and "1" as synonyms for "false" and "true" in boolean config options. However, we don't actually handle those values in git_config_maybe_bool. In most cases this works fine, as we call git_config_bool, which in turn calls git_config_bool_or_int, which in turn calls git_config_maybe_bool. Values of 0/1 are considered "not bool", but their integer values end up being converted to the corresponding boolean values. However, the log.decorate code looks for maybe_bool explicitly, so that it can fall back to the "short" and "full" strings. It does not handle 0/1 at all, and considers them invalid values. We cannot simply add 0/1 support to git_config_maybe_bool. That would confuse git_config_bool_or_int, which may want to distinguish the integer values "0" and "1" from bools. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'revision.c')
0 files changed, 0 insertions, 0 deletions