git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Couder <chriscool@tuxfamily.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Junio C Hamano <gitster@pobox.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Alternative approach to the git config NULL value checking patches..
Date: Mon, 11 Feb 2008 08:22:08 +0100	[thread overview]
Message-ID: <200802110822.08902.chriscool@tuxfamily.org> (raw)
In-Reply-To: <alpine.LFD.1.00.0802101532070.2920@woody.linux-foundation.org>

Le lundi 11 février 2008, Linus Torvalds a écrit :
> On Sun, 10 Feb 2008, Junio C Hamano wrote:
> >
> > My answer to your question is: "It is not different
> > from checking against NULL at all."
>
> Of course it is.
>
> Not using NULL means that things like
>
> 	strcmp()
> 	atoi()
> 	..
>
> all work and automatically get the right answer and don't need to care.

I agree.

> Take a look at the NULL-compare patches. 90% of them are just noise.

That's right.

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". In my 
opinion it is much more likely (95% against 5%) to be a typo than someone 
so lazy as to prefer only "var =" over "var = false".

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

By the way deprecating does not mean breaking it and not fixing where it 
breaks. It just means we think it's bad and it should not be used. We can 
even decide to keep the same boolean meaning (that is "false") for "var ="
latter if we have a good way to deal with the cruft and if we really don't 
want to break things.

And even if we latter change "var =" to mean "true", we can still keep a 
warning by checking using Linus' trick:

int git_config_bool(const char *name, const char *value)
{
        if (value == config_true)
                return 1;
        if (!*value) {
                fprintf(stderr,
                        "Warning: using an empty value for boolean config "
                        "variables is deprecated and dangerous.\n"
                        "An empty value now means 'true' as a "
                        "boolean, but meant 'false' in previous git "
                        "versions!\n"
                        "Please consider using a 'true' (or 'false') value "
                        "explicitely for variable '%s', so that your "
                        "config is git version independant. "
                        "You can do that using for example:\n"
                        "\tgit config %s true\n", name, name);
               return 1;
       }
       if (!strcasecmp(value, "true") || !strcasecmp(value, "yes"))
               return 1;
       if (!strcasecmp(value, "false") || !strcasecmp(value, "no"))
		return 0;
	return git_config_int(name, value) != 0;
}

Or we could even (using Linus' trick) make it an error and just "die" in 
this case.

Christian (now urgently looking for a flame proof suit).

  parent reply	other threads:[~2008-02-11  7:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-10 20:32 Alternative approach to the git config NULL value checking patches Linus Torvalds
2008-02-10 21:25 ` Junio C Hamano
2008-02-10 22:08   ` Linus Torvalds
2008-02-10 22:29     ` Junio C Hamano
2008-02-10 22:47       ` Junio C Hamano
2008-02-10 23:29         ` Pierre Habouzit
2008-02-10 23:50           ` Linus Torvalds
2008-02-10 23:36       ` Linus Torvalds
2008-02-10 23:41         ` Linus Torvalds
2008-02-11  0:40           ` Junio C Hamano
2008-02-11  7:22         ` Christian Couder [this message]
2008-02-11  8:12           ` Junio C Hamano
2008-02-11 17:27   ` Daniel Barkalow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200802110822.08902.chriscool@tuxfamily.org \
    --to=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).