Jeff King [off-list ref] writes:
On Fri, Jul 11, 2014 at 02:54:25PM -0700, Junio C Hamano wrote:
quoted
quoted
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:
...
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".
Yeah, somehow I was mixing up these two cases fuzzily in my mind
while responding. Rejecting unknown keys is bad, but we cannot be
perfectly forward compatible nor behave sensibly on unknown values
while issuing errors against known-to-be-bad values, so your rule
above sounds like the most sensible thing to do.
-----Original Message-----
From: Junio C Hamano [mailto:gitster@pobox.com]
Sent: Sunday, July 13, 2014 10:01 AM
To: Jeff King
Cc: Keller, Jacob E; git@vger.kernel.org
Subject: Re: [PATCH 3/3 v5] tag: support configuring --sort via .gitconfig
Jeff King [off-list ref] writes:
quoted
On Fri, Jul 11, 2014 at 02:54:25PM -0700, Junio C Hamano wrote:
quoted
quoted
Yeah, we're quite inconsistent there. In some cases we silently
ignore
quoted
quoted
quoted
something unknown (e.g., a color.diff.* slot that we do not
understand),
quoted
quoted
quoted
but in most cases if it is a config key we understand but a value we
do
quoted
quoted
quoted
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:
...
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".
Yeah, somehow I was mixing up these two cases fuzzily in my mind
while responding. Rejecting unknown keys is bad, but we cannot be
perfectly forward compatible nor behave sensibly on unknown values
while issuing errors against known-to-be-bad values, so your rule
above sounds like the most sensible thing to do.
The only difference is whether we halt or ignore the unknown value we complained about. Personally I am ok with either, but prefer the "complain and choose the default" so that older gits don't completely stop. But in some cases, the change is not easily compatible so then stopping might be preferred as the old git will not behave as expected.
Thanks,
Jake