Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx> writes:
>On Tue, Oct 18, 2011 at 01:13, Pat Thoyts
><patthoyts@xxxxxxxxxxxxxxxxxxxxx> wrote:
>> Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx> writes:
>>
>>>When git interprets a config variable without a value as bool it is considered
>>>as true. But git-gui doesn't so until yet.
>>>
>>>The value for boolean configs are also case-insensitive.
>>>
>>>Signed-off-by: Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx>
>>>---
>>> git-gui.sh | 16 ++++++++++++++--
>>> 1 files changed, 14 insertions(+), 2 deletions(-)
>>>
>>>diff --git a/git-gui.sh b/git-gui.sh
>>>index f897160..d687871 100755
>>>--- a/git-gui.sh
>>>+++ b/git-gui.sh
>>>@@ -299,7 +299,9 @@ proc is_config_true {name} {
>>> global repo_config
>>> if {[catch {set v $repo_config($name)}]} {
>>> return 0
>>>- } elseif {$v eq {true} || $v eq {1} || $v eq {yes}} {
>>>+ }
>>>+ set v [string tolower $v]
>>>+ if {$v eq {} || $v eq {true} || $v eq {1} || $v eq {yes} || $v eq {on}} {
>>> return 1
>>> } else {
>>> return 0
>>
>> This looks ok - we actually have a [string is boolean $v] test we could
>> use eg:
>> if {[string is boolean $v]} {
>> return [expr {$v eq {} ? 1 : !!$v}]
>> }
>> although I'm not sure it gains us much. This would match everything Tcl
>> believes to be a boolean - yes/no, on/off, true/false and 1/0. Without
>> -strict the [string is] test will consider {} to be a boolean.
>>
>>
>>>@@ -310,7 +312,9 @@ proc is_config_false {name} {
>>> global repo_config
>>> if {[catch {set v $repo_config($name)}]} {
>>> return 0
>>>- } elseif {$v eq {false} || $v eq {0} || $v eq {no}} {
>>>+ }
>>>+ set v [string tolower $v]
>>>+ if {$v eq {false} || $v eq {0} || $v eq {no} || $v eq {off}} {
>>> return 1
>>> } else {
>>> return 0
>>>@@ -1060,6 +1064,10 @@ git-version proc _parse_config {arr_name args} {
>>> } else {
>>> set arr($name) $value
>>> }
>>>+ } elseif {[regexp {^([^\n]+)$} $line line name]} {
>>>+ # no value given, but interpreting them as
>>>+ # boolean will be handled as true
>>>+ set arr($name) {}
>>> }
>>> }
>>> }
>>>@@ -1075,6 +1083,10 @@ git-version proc _parse_config {arr_name args} {
>>> } else {
>>> set arr($name) $value
>>> }
>>>+ } elseif {[regexp {^([^=]+)$} $line line name]} {
>>>+ # no value given, but interpreting them as
>>>+ # boolean will be handled as true
>>>+ set arr($name) {}
>>> }
>>> }
>>> close $fd_rc
>>
>> Is this really how git treats boolean config values? I can't seem to
>> demonstrate that to myself:
>> pat@frog:/opt/src/git-gui$ git config --unset core.xyzzy
>> pat@frog:/opt/src/git-gui$ git config --bool --get core.xyzzy
>> pat@frog:/opt/src/git-gui$ git config --bool core.xyzzy 1
>> pat@frog:/opt/src/git-gui$ git config --bool --get core.xyzzy
>> true
>>
>> I assume I'm using the wrong test for this.
>
>It looks like you can't set it with git-config. But I know, that writing:
>
>[core]
> xyyzy
>
>into the git config file and than calling git config --bool --get
>core.xyzzy, will give you true.
>
>Bert
OK thanks for explaining.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
--
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