From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "SZEDER Gábor" <szeder@ira.uka.de>,
"Christian Couder" <christian.couder@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH 2/3] format_config: simplify buffer handling
Date: Fri, 21 Aug 2015 10:42:44 -0700 [thread overview]
Message-ID: <xmqqvbc85yi3.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20150820144733.GB11913@sigill.intra.peff.net> (Jeff King's message of "Thu, 20 Aug 2015 10:47:34 -0400")
Jeff King <peff@peff.net> writes:
> When formatting a config value into a strbuf, we may end
> up stringifying it into a fixed-size buffer using sprintf,
> and then copying that buffer into the strbuf. We can
> eliminate the middle-man (and drop some calls to sprintf!)
> by writing directly to the strbuf.
>
> The reason it was written this way in the first place is
> that we need to know before writing the value whether to
> insert a delimiter. Instead of delaying the write of the
> value, we speculatively write the delimiter, and roll it
> back in the single case that cares.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I admit the rollback is a little gross. The other option would be adding
> the delimiter in each of the conditional branches, which is also kind of
> nasty.
I actually am fine with this rollback. The "variable alone stands
for true" is not something a user can produce from the command line
very easily, so having to rollback is a rare event anyway.
I wonder if we can do this instead
if (!omit_values) {
- if (show_keys)
+ if (show_keys && value_)
strbuf_addch(buf, key_delim);
though. That would eliminate the need for rolling back.
I briefly wondered how such a change would interact with
if (types == TYPE_INT)
strbuf_addf(buf, "%"PRId64,
git_config_int64(key_, value_ ? value_ : ""));
that immediately follows it, but this "turn NULL into an empty
string" may be bogus in the first place, in the sense that
git_config_int64() should complain about a NULL value_ the same way
as it would complain about an empty string---both them are not an
integer. And indeed:
- git_parse_int64() that is called from git_config_int64() is
prepared to take both "" and NULL and return failure with EINVAL;
- die_bad_number() that is eventually called when parsing fails by
git_config_int64() is prepared to take NULL and turns it to an
empty string.
So perhaps we could do this squashed in?
builtin/config.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index 71acc44..593b1ae 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -111,12 +111,12 @@ static int format_config(struct strbuf *buf, const char *key_, const char *value
if (show_keys)
strbuf_addstr(buf, key_);
if (!omit_values) {
- if (show_keys)
+ if (show_keys && value_)
strbuf_addch(buf, key_delim);
if (types == TYPE_INT)
strbuf_addf(buf, "%"PRId64,
- git_config_int64(key_, value_ ? value_ : ""));
+ git_config_int64(key_, value_));
else if (types == TYPE_BOOL)
strbuf_addstr(buf, git_config_bool(key_, value_) ?
"true" : "false");
@@ -136,9 +136,8 @@ static int format_config(struct strbuf *buf, const char *key_, const char *value
} else if (value_) {
strbuf_addstr(buf, value_);
} else {
- /* Just show the key name; back out delimiter */
- if (show_keys)
- strbuf_setlen(buf, buf->len - 1);
+ /* Just show the key name */
+ ;
}
}
strbuf_addch(buf, term);
next prev parent reply other threads:[~2015-08-21 17:42 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-10 9:46 [PATCHv3 0/2] 'git config --names-only' to help the completion script SZEDER Gábor
2015-08-10 9:46 ` [PATCHv3 1/2] config: add '--names-only' option to list only variable names SZEDER Gábor
2015-08-10 13:41 ` Jeff King
2015-08-10 17:18 ` Junio C Hamano
2015-08-12 23:47 ` SZEDER Gábor
2015-08-13 1:39 ` Junio C Hamano
2015-08-20 14:14 ` [PATCH] config: restructure format_config() for better control flow SZEDER Gábor
2015-08-20 14:45 ` Jeff King
2015-08-20 14:46 ` [PATCH 1/3] format_config: don't init strbuf Jeff King
2015-08-20 14:47 ` [PATCH 2/3] format_config: simplify buffer handling Jeff King
2015-08-21 11:52 ` SZEDER Gábor
2015-08-21 17:42 ` Junio C Hamano [this message]
2015-08-21 17:43 ` Junio C Hamano
2015-08-21 19:40 ` Jeff King
2015-08-20 14:49 ` [PATCH 3/3] get_urlmatch: avoid useless strbuf write Jeff King
2015-08-20 20:19 ` [PATCH] config: restructure format_config() for better control flow Junio C Hamano
2015-08-10 9:46 ` [PATCHv3 2/2] completion: list variable names reliably with 'git config --names-only' SZEDER Gábor
2015-08-10 13:45 ` Jeff King
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=xmqqvbc85yi3.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=szeder@ira.uka.de \
/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.