Re: [PATCH 3/3 v5] tag: support configuring --sort via .gitconfig

From: Jeff King <peff@peff.net>
Date: Jul 12, 2014, 01:17 UTC
Message-ID: <20140712011735.GB17349@sigill.intra.peff.net>
In-Reply-To: <xmqqmwcf36jy.fsf@gitster.dls.corp.google.com>

On Fri, Jul 11, 2014 at 02:54:25PM -0700, Junio C Hamano wrote:

Show 7 quoted lines

> > 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