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