Re: Alternative approach to the git config NULL value checking patches..

Christian Couder [off-list ref] writes:

Now the 10% are only when we have a boolean variable and we want it to 
be "false" when there is:

[foo]
	var =

while:

[foo]
	var

is considered "true".

And let's face it, it's not obvious at all why it should be false if there 
is "var =" and true when there is only "var". Is it a Microsoft standard ?
Do we really care about it ?
...
I also doubt that many users willingly use "var =" to mean "false".

Some variables started their life as boolean and "[foo] var" is
true and "[foo] var = false" (or "= 0") is false for them; later
they acquired third or more options to have string values.

For such a variable:

	[foo] var	    ; boolean "true"
        [foo] var = "true"  ; boolean "true"
        [foo] var = "false" ; boolean "false"
	[foo] var = ""	    ; boolean "false", too.
        [foo] var =         ; perhaps misspelled, perhaps the same as above.
	[foo] var = "value" ; string (new semantics)

and adding a warning for the fifth one (but not fourth one)
might be a good idea.

I have a bit stronger opinion on keeping "[foo] var" (without an
equal sign) to stay "true".  Especially, making it exactly the
same as an empty string is unacceptable, if it is done without
Linus's trick to make it distinguishable internally.

Luckily, the calls to get_config_set() we internally make
in-tree (e.g. git-init sets core.filemode and friends) are all
very explicit and do not write "[foo] var" form of truth.  But
many existing docs written outside our (my) control that google
finds say "Put '[core] autocrlf' in your .git/config".  You do
not want to break the repositories configured following such an
advice.

So let's do them (and ourself too) a favor and deprecate "var =" to mean 
false. I will post my patch to do this.

Don't do it if you cannot differentiate between the fourth and
the fifth in the above listing.