On boolean configuration variables...

On boolean configuration variables...

[Junio C Hamano]

Boolean configuration variables in $GIT_DIR/config are a bit
strange.

	[bool]
        	var1
                var2 =
                var3 = true
                var4 = yes
                var5 = 1
                var6 = 2
                var7 = false
                var8 = no
                var9 = 0

var1, var3, var5, and var6 are "true"; var2, var7 and var9 are
"false".  var4 and var8 are syntax errors.

Currently "git repo-config --bool --get bool.var1" returns
"false", which is fixed by the attached patch, but I am
wondering if it is a good idea to allow "yes" and "no" as well.

-- >8 --
[PATCH] repo-config: fix printing of bool

When a bool variable appears without any value, it means true.
However, replacing the NULL value with an empty string, an earlier
commit f067a13745fbeae1aa357876348a00e5edd0a629 broke show-config.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 repo-config.c |    9 +++------
 1 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/repo-config.c b/repo-config.c
index ab8f1af..743f02b 100644
--- a/repo-config.c
+++ b/repo-config.c
@@ -29,16 +29,13 @@ static int show_config(const char* key_,
 	const char *vptr = value;
 	int dup_error = 0;
 
-	if (value_ == NULL)
-		value_ = "";
-
 	if (!use_key_regexp && strcmp(key_, key))
 		return 0;
 	if (use_key_regexp && regexec(key_regexp, key_, 0, NULL, 0))
 		return 0;
 	if (regexp != NULL &&
 			 (do_not_match ^
-			  regexec(regexp, value_, 0, NULL, 0)))
+			  regexec(regexp, (value_?value_:""), 0, NULL, 0)))
 		return 0;
 
 	if (show_keys)
@@ -46,11 +43,11 @@ static int show_config(const char* key_,
 	if (seen && !do_all)
 		dup_error = 1;
 	if (type == T_INT)
-		sprintf(value, "%d", git_config_int(key_, value_));
+		sprintf(value, "%d", git_config_int(key_, value_?value_:""));
 	else if (type == T_BOOL)
 		vptr = git_config_bool(key_, value_) ? "true" : "false";
 	else
-		vptr = value_;
+		vptr = value_?value_:"";
 	seen++;
 	if (dup_error) {
 		error("More than one value for the key %s: %s",
-- 
1.4.1.rc1.ga77b7

Re: On boolean configuration variables...

[Anand Kumria]

On Sat, 24 Jun 2006 05:28:02 -0700, Junio C Hamano wrote:

> Boolean configuration variables in $GIT_DIR/config are a bit
> strange.
> 
> 	[bool]
>         	var1
>                 var2 =
>                 var3 = true
>                 var4 = yes
>                 var5 = 1
>                 var6 = 2
>                 var7 = false
>                 var8 = no
>                 var9 = 0
> 
> var1, var3, var5, and var6 are "true"; var2, var7 and var9 are
> "false".  var4 and var8 are syntax errors.
> 
> Currently "git repo-config --bool --get bool.var1" returns
> "false", which is fixed by the attached patch, but I am
> wondering if it is a good idea to allow "yes" and "no" as well.
> 

Allowing 'yes' and 'no' to equal 'true' and 'false' respectively sounds
pretty sane and user-friendly.

Why wouldn't you want to do that?

Anand

Re: On boolean configuration variables...

[Johannes Schindelin]

Hi,

On Sun, 25 Jun 2006, Anand Kumria wrote:

> Allowing 'yes' and 'no' to equal 'true' and 'false' respectively sounds
> pretty sane and user-friendly.
> 
> Why wouldn't you want to do that?

'Cause you'd have to add "maybe", too ;-)

Seriously, there is a subtle side to booleans, which is the reason that 
they typically take on only "false" and "true": Consider the question "Is 
the box not red?". If the answer is "yes", I do not know if "yes, the box 
is red" or "yes, the box is not red".

"true" and "false" are less ambiguous.

Ciao,
Dscho

Re: On boolean configuration variables...

[Anand Kumria]

On Sun, Jun 25, 2006 at 04:00:34PM +0200, Johannes Schindelin wrote:
> Hi,
> 
> On Sun, 25 Jun 2006, Anand Kumria wrote:
> 
> > Allowing 'yes' and 'no' to equal 'true' and 'false' respectively sounds
> > pretty sane and user-friendly.
> > 
> > Why wouldn't you want to do that?
> 
> 'Cause you'd have to add "maybe", too ;-)
> 
> Seriously, there is a subtle side to booleans, which is the reason that 
> they typically take on only "false" and "true": Consider the question "Is 
> the box not red?". If the answer is "yes", I do not know if "yes, the box 
> is red" or "yes, the box is not red".
> 
> "true" and "false" are less ambiguous.

"True, the box is red" and "true, the box is not red" are just as ambiguous.
It is always ambiguous if you allow a qualifier.

Cheers,
Anand

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"