{"thread":{"id":"4651","subject":"On boolean configuration variables...","startedAt":"2006-06-24T12:28:02Z","lastAt":"2006-06-25T15:41:45Z","messageCount":4,"participants":["Junio C Hamano","Anand Kumria","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"22444","messageId":"7vy7vmviul.fsf@assigned-by-dhcp.cox.net","threadId":"4651","inReplyTo":null,"subject":"On boolean configuration variables...","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-24T12:28:02Z","receivedAt":"2006-06-24T12:28:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Boolean configuration variables in $GIT_DIR/config are a bit\nstrange.\n\n\t[bool]\n        \tvar1\n                var2 =\n                var3 = true\n                var4 = yes\n                var5 = 1\n                var6 = 2\n                var7 = false\n                var8 = no\n                var9 = 0\n\nvar1, var3, var5, and var6 are \"true\"; var2, var7 and var9 are\n\"false\".  var4 and var8 are syntax errors.\n\nCurrently \"git repo-config --bool --get bool.var1\" returns\n\"false\", which is fixed by the attached patch, but I am\nwondering if it is a good idea to allow \"yes\" and \"no\" as well.\n\n-- >8 --\n[PATCH] repo-config: fix printing of bool\n\nWhen a bool variable appears without any value, it means true.\nHowever, replacing the NULL value with an empty string, an earlier\ncommit f067a13745fbeae1aa357876348a00e5edd0a629 broke show-config.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n repo-config.c |    9 +++------\n 1 files changed, 3 insertions(+), 6 deletions(-)\n\ndiff --git a/repo-config.c b/repo-config.c\nindex ab8f1af..743f02b 100644\n--- a/repo-config.c\n+++ b/repo-config.c\n@@ -29,16 +29,13 @@ static int show_config(const char* key_,\n \tconst char *vptr = value;\n \tint dup_error = 0;\n \n-\tif (value_ == NULL)\n-\t\tvalue_ = \"\";\n-\n \tif (!use_key_regexp && strcmp(key_, key))\n \t\treturn 0;\n \tif (use_key_regexp && regexec(key_regexp, key_, 0, NULL, 0))\n \t\treturn 0;\n \tif (regexp != NULL &&\n \t\t\t (do_not_match ^\n-\t\t\t  regexec(regexp, value_, 0, NULL, 0)))\n+\t\t\t  regexec(regexp, (value_?value_:\"\"), 0, NULL, 0)))\n \t\treturn 0;\n \n \tif (show_keys)\n@@ -46,11 +43,11 @@ static int show_config(const char* key_,\n \tif (seen && !do_all)\n \t\tdup_error = 1;\n \tif (type == T_INT)\n-\t\tsprintf(value, \"%d\", git_config_int(key_, value_));\n+\t\tsprintf(value, \"%d\", git_config_int(key_, value_?value_:\"\"));\n \telse if (type == T_BOOL)\n \t\tvptr = git_config_bool(key_, value_) ? \"true\" : \"false\";\n \telse\n-\t\tvptr = value_;\n+\t\tvptr = value_?value_:\"\";\n \tseen++;\n \tif (dup_error) {\n \t\terror(\"More than one value for the key %s: %s\",\n-- \n1.4.1.rc1.ga77b7\n"},{"id":"22555","messageId":"e7m3b6$eoa$1@sea.gmane.org","threadId":"4651","inReplyTo":"7vy7vmviul.fsf@assigned-by-dhcp.cox.net","subject":"Re: On boolean configuration variables...","fromName":"Anand Kumria","fromEmail":"wildfire@progsoc.org","sentAt":"2006-06-25T13:33:26Z","receivedAt":"2006-06-25T13:33:26Z","isPatch":false,"sender":{"key":"wildfire@progsoc.org","avatar":null},"body":"On Sat, 24 Jun 2006 05:28:02 -0700, Junio C Hamano wrote:\n\n> Boolean configuration variables in $GIT_DIR/config are a bit\n> strange.\n> \n> \t[bool]\n>         \tvar1\n>                 var2 =\n>                 var3 = true\n>                 var4 = yes\n>                 var5 = 1\n>                 var6 = 2\n>                 var7 = false\n>                 var8 = no\n>                 var9 = 0\n> \n> var1, var3, var5, and var6 are \"true\"; var2, var7 and var9 are\n> \"false\".  var4 and var8 are syntax errors.\n> \n> Currently \"git repo-config --bool --get bool.var1\" returns\n> \"false\", which is fixed by the attached patch, but I am\n> wondering if it is a good idea to allow \"yes\" and \"no\" as well.\n> \n\nAllowing 'yes' and 'no' to equal 'true' and 'false' respectively sounds\npretty sane and user-friendly.\n\nWhy wouldn't you want to do that?\n\nAnand\n"},{"id":"22559","messageId":"Pine.LNX.4.63.0606251553110.29667@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4651","inReplyTo":"e7m3b6$eoa$1@sea.gmane.org","subject":"Re: On boolean configuration variables...","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-06-25T14:00:34Z","receivedAt":"2006-06-25T14:00:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 25 Jun 2006, Anand Kumria wrote:\n\n> Allowing 'yes' and 'no' to equal 'true' and 'false' respectively sounds\n> pretty sane and user-friendly.\n> \n> Why wouldn't you want to do that?\n\n'Cause you'd have to add \"maybe\", too ;-)\n\nSeriously, there is a subtle side to booleans, which is the reason that \nthey typically take on only \"false\" and \"true\": Consider the question \"Is \nthe box not red?\". If the answer is \"yes\", I do not know if \"yes, the box \nis red\" or \"yes, the box is not red\".\n\n\"true\" and \"false\" are less ambiguous.\n\nCiao,\nDscho\n"},{"id":"22567","messageId":"20060625154145.GT10850@progsoc.uts.edu.au","threadId":"4651","inReplyTo":"Pine.LNX.4.63.0606251553110.29667@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: On boolean configuration variables...","fromName":"Anand Kumria","fromEmail":"wildfire@progsoc.org","sentAt":"2006-06-25T15:41:45Z","receivedAt":"2006-06-25T15:41:45Z","isPatch":false,"sender":{"key":"wildfire@progsoc.org","avatar":null},"body":"On Sun, Jun 25, 2006 at 04:00:34PM +0200, Johannes Schindelin wrote:\n> Hi,\n> \n> On Sun, 25 Jun 2006, Anand Kumria wrote:\n> \n> > Allowing 'yes' and 'no' to equal 'true' and 'false' respectively sounds\n> > pretty sane and user-friendly.\n> > \n> > Why wouldn't you want to do that?\n> \n> 'Cause you'd have to add \"maybe\", too ;-)\n> \n> Seriously, there is a subtle side to booleans, which is the reason that \n> they typically take on only \"false\" and \"true\": Consider the question \"Is \n> the box not red?\". If the answer is \"yes\", I do not know if \"yes, the box \n> is red\" or \"yes, the box is not red\".\n> \n> \"true\" and \"false\" are less ambiguous.\n\n\"True, the box is red\" and \"true, the box is not red\" are just as ambiguous.\nIt is always ambiguous if you allow a qualifier.\n\nCheers,\nAnand\n\n-- \n `When any government, or any church for that matter, undertakes to say to\n  its subjects, \"This you may not read, this you must not see, this you are\n  forbidden to know,\" the end result is tyranny and oppression no matter how\n  holy the motives' -- Robert A Heinlein, \"If this goes on --\"\n"}]}