Re: Local unset override global options

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

 



On Mon, Apr 12, 2010 at 4:48 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> 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.

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

Knowing that variables are never unset internally gives me a different
perspective.  Thanks for the explanation.

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