From: Pierre Habouzit <madcoder@debian.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: Alternative approach to the git config NULL value checking patches..
Date: Mon, 11 Feb 2008 00:29:20 +0100 [thread overview]
Message-ID: <20080210232920.GH5129@artemis.madism.org> (raw)
In-Reply-To: <7v7ihce8ex.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]
On Sun, Feb 10, 2008 at 10:47:02PM +0000, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > But as you seem to imply, it might make sense to equate
> >
> > [some-random-section]
> > some-random-variable
> >
> > to
> >
> > [some-random-section]
> > some-random-variable = ""
> >
> > for variables that cannot possibly have any meaningful "bool"
> > semantics. This third class of variables is a possible benefit
> > your patch brings in. The code can be lax for these variables.
> >
> > However, it would make things inconsistent ("this variable is
> > bool and the above two forms mean completely opposite things,
> > while that variable is not bool and they mean the same thing").
> > I am just having a hard time convincing myself that this little
> > detail does not matter.
>
> Having said all that, it might be an option to change your patch
> slightly to say:
>
> const char config_true[] = "true";
I was about to suggest the same, and testing against "config_true" just
becomes an optimization, but isn't required. Seems an appropriate hack
to me.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2008-02-10 23:30 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 [this message]
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
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=20080210232920.GH5129@artemis.madism.org \
--to=madcoder@debian.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.