> -----Original Message----- > From: Junio C Hamano [mailto:gitster@xxxxxxxxx] > Sent: Sunday, July 13, 2014 10:01 AM > To: Jeff King > Cc: Keller, Jacob E; git@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 3/3 v5] tag: support configuring --sort via .gitconfig > > Jeff King <peff@xxxxxxxx> writes: > > > 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: > > ... > > 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 -- 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