Re: Local unset override global options

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stefan Hajnoczi <stefanha@xxxxxxxxx> writes:

> That would work but introduces a special case for smtpuser.  Do you
> think users may wish to unset override other options too?

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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]