On Fri, Jul 11, 2014 at 02:54:25PM -0700, Junio C Hamano wrote:
> > Yeah, we're quite inconsistent there. In some cases we silently ignore
> > something unknown (e.g., a color.diff.* slot that we do not understand),
> > but in most cases if it is a config key we understand but a value we do
> > not, we complain and die.
>
> Hm, that's bad---we've become less and less careful over time,
> perhaps?
I don't think so. I think we've always been not-very-lenient with
parsing values. Two examples:
1. We sometimes extend a boolean variable to take additional values
(like "auto" or "always"). Older gits will see those values and say
"not a boolean, and also not a number" and barf.
branch.autosetupmerge is an example of this (it learned "always" in
9ed36cf.
2. The parser for colors translates things like "bold" into ANSI
codes. If it doesn't understand a keyword, it dies. If we add new
color names or attributes, they will cause older git to die.
There are many cases like this. Pretty much any enumerated value
(like branch.autosetuprebase, for example) will face this whenever
we add new possible values.
So I do not think we have ever had a rule, but if we did, it is probably
"silently ignore unknown keys, complain on unknown values". Which makes
warning on tag.sort unlike most of the rest of the code.
I do not mind it, though (I am one of the people it is most likely to
help :) ). Just giving some context.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html