Re: Local unset override global options

Stefan Hajnoczi <stefanha@gmail.com> writes:

I would indeed agree "users may _wish_ to", but that does not matter as much as "users _need_ to, otherwise they cannot do X and Y and Z".

You seem to think from the beginning of this thread that "empty means I don't want it" is a hacky special case that is limited to this smtpuser variable, but I do not share that view. Not at all.

In fact, "empty means I don't want it" is a very common convention even outside the context of git. Make's use of its variables is a good example. Many people's shell scripts tend to treat an empty variable and an unset variable the same way. The language itself does distinguish an empty and an unset variable, but the colon form of ${var:-something} was invented in addition to the more old fashioned ${var-something} exactly because "empty means unset" is so common. Perl (run without -w/strict) is the same way and undef becomes empty string by default and you need to actively check defined($var) if you care about the difference. Etc. etc.

There are two rather big reasons we would want to stick to the current format without introducing "unset". At least we would want to try to until we find real need that justifies such a change.

 - We could introduce a backward incompatible change to the configuration
   file format to say "This variable is not set at all", but once somebody
   starts using the syntax in his .git/config (or worse $HOME/.gitconfig),
   that repository cannot be used by older version of git anymore.

 - Also internally our variables are never "unset".  Behaviour of a
   plumbing or Porcelain command implemented in C is controlled by
   variables in C, and the contents of the configuration files overwrite
   these variables as they are parsed from the least specific (system) to
   the most specific.  The best you can do is "reset to default" (not
   "unset"), and even that involves fair amount of change.