git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [bug] generic issue with git_config handlers

From
Christian Couder <chriscool@tuxfamily.org>
Date
Feb 7, 2008, 05:45 UTC
Message-ID
<200802070645.23840.chriscool@tuxfamily.org>
In-Reply-To
<7vk5lki815.fsf@gitster.siamese.dyndns.org>
Le mardi 5 février 2008, Junio C Hamano a écrit :
Show 8 quoted lines
> Christian Couder <chriscool@tuxfamily.org> writes:
> > Very unfortunate.
> >
> > I finally had the following patch that passed all tests (it changed
> > only one test), in case someone wants to suggest that we change
> > git_config_bool, hint, hint!
>
> Sorry, I do not get what you are hinting at. 

Well, I wanted someone else to suggest that we deprecate using "" as a boolean false.

Something like this (completely untested) :
diff --git a/config.c b/config.c
index 526a3f4..44afeaa 100644
--- a/config.c
+++ b/config.c
@@ -300,8 +300,19 @@ int git_config_bool(const char *name, const char 
*value)
 {
        if (!value)
                return 1;
-       if (!*value)
+       if (!*value) {
+               fprintf(stderr,
+                       "Warning: using an empty value for boolean config "
+                       "variables is deprecated.\n"
+                       "An empty value currently means 'false' as a "
+                       "boolean, but may very well means 'true' in the "
+                       "future!\n"
+                       "Please consider using a 'false' value explicitely "
+                       "for variable '%s', so that your config is future "
+                       "proof. You can do that using:\n"
+                       "\tgit config %s false\n", name, name)
                return 0;
+       }
        if (!strcasecmp(value, "true") || !strcasecmp(value, "yes"))
                return 1;
        if (!strcasecmp(value, "false") || !strcasecmp(value, "no"))

So that in a future version we can use "" internaly for both no value and 
empty value variables and consider them meaning the same.

> The fact that you
> passed all the tests suggests that we have a gap in the test
> coverage for these two, so you are inviting more tests from
> others?

I just sent a patch to close this gap.

[...]

> Your "builtin-config.c" patch looks better than before (which
> would segfault), but I think
>
> 	$ git config --bool --list
>
> could pay attention to the "type" thing set earlier, just like
> show_config() does.

I didn't try this, but I will.

Thanks,
Christian.
Previous: Junio C Hamano
Message 8 of 8 in “[bug] generic issue with git_config handlers”
  1. Pierre HabouzitJan 31, 2008
  2. Junio C HamanoJan 31, 2008
  3. Pierre HabouzitJan 31, 2008
  4. Christian CouderFeb 4, 2008
  5. Johannes SixtFeb 4, 2008
  6. Christian CouderFeb 4, 2008
  7. Junio C HamanoFeb 5, 2008
  8. Christian CouderFeb 7, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.