From: Junio C Hamano <gitster@pobox.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: Sam Vilain <sam.vilain@catalyst.net.nz>,
Frank Lichtenheld <frank@lichtenheld.de>,
git@vger.kernel.org, Petr Baudis <pasky@suse.cz>
Subject: Re: [PATCH] perl: add new module Git::Config for cached 'git config' access
Date: Tue, 07 Apr 2009 23:29:59 -0700 [thread overview]
Message-ID: <7vbpr7r72w.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <m3prfo1xh6.fsf@localhost.localdomain> (Jakub Narebski's message of "Tue, 07 Apr 2009 05:01:37 -0700 (PDT)")
Jakub Narebski <jnareb@gmail.com> writes:
> Errr... wouldn't it be better to simply use
>
> + my ($item, $value) = split("\n", $_, 2)
>
> here? Have you tested Git::Config with a "null" value, i.e. something
> like
>
> [section]
> noval
>
> in the config file (which evaluates to 'true' with '--bool' option)?
> Because from what I remember from the discussion on the
> "git config --null --list" format the lack of "\n" is used to
> distinguish between noval (which is equivalent to 'true'), and empty
> value (which is equivalent to 'false')
>
> [boolean
> noval # equivalent to 'true'
> empty1 = # equivalent to 'false'
> empty2 = "" # equivalent to 'false'
I do not mind if the _write method always wrote out
[core]
autocrlf = true
for a variable that is true, but it should be able to read existing
[core]
autocrlf
correctly.
Sam, I think you meant to make me squash the "Oops, for no good reason,
here is a fix-up" into the previous one, but for this case, I'd appreciate
a re-roll of the series, that includes a test to read from an existing
configuration file that contains such "presense of the name alone means
boolean true" variables.
next prev parent reply other threads:[~2009-04-08 6:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-05 23:46 [PATCH] perl: add new module Git::Config for cached 'git config' access Sam Vilain
2009-04-05 23:46 ` [PATCH] perl: make Git.pm use new Git::Config module Sam Vilain
2009-04-06 9:29 ` [PATCH] perl: add new module Git::Config for cached 'git config' access Frank Lichtenheld
2009-04-06 22:50 ` Sam Vilain
2009-04-07 12:01 ` Jakub Narebski
2009-04-08 5:49 ` Sam Vilain
2009-04-08 10:18 ` Jakub Narebski
2009-04-08 10:44 ` Sam Vilain
2009-04-08 23:13 ` Jakub Narebski
2009-04-08 6:29 ` Junio C Hamano [this message]
2009-04-08 9:50 ` Sam Vilain
2009-04-08 18:51 ` Junio C Hamano
2009-04-08 8:12 ` Petr Baudis
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=7vbpr7r72w.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=frank@lichtenheld.de \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=pasky@suse.cz \
--cc=sam.vilain@catalyst.net.nz \
/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.