From: Jeff King <peff@peff.net>
Date: Mon, 16 May 2011 11:05:45 GMT
Subject: Re: RFC proposal: set git defaults options from config
Message-ID: <20110516110545.GC23889@sigill.intra.peff.net>
In-Reply-To: <2235D93D-4F02-42D7-88B1-74F692D58AA5@gmail.com>

On Thu, May 12, 2011 at 03:36:16PM -0700, David Pisoni wrote:

> This has some interesting implications.  Consider the case at hand:
> git-stash --index is a boolean switch.  It was not the default state,
> and it lacked any configuration override, so there was no
> '--no-index' switch provided.  If we make this change to git,
> presumably EVERY boolean flag like this in all the git subcommands
> needs to be backed with a '--no' counterpart.

Most of them already are, by virtue of parse-options. And I don't
think it's a bad thing for those that don't have one to get one.

> Thinking this through a little further, there is the potential to
> want to override the configured value (in the case of non-booleans)
> with an explicit command line switch.  So now we have "precedence
> rules" for subcommand options. Probably simple to handle this for
> single vars, but harder for multivars.

For single vars, which are most of it, it is pretty simple. For
multivars, mostly "--no-$option" should reset the multivar list
explicitly. I expect there are some oddballs where that is not the case,
though. For example, we just recently found some confusion with
resetting "git status" to its default after seeing "--porcelain".
So there would probably be some cleanup work there.

-Peff