From: Junio C Hamano <gitster@pobox.com>
To: Tanay Abhra <tanayabh@gmail.com>
Cc: git@vger.kernel.org, Ramkumar Ramachandra <artagnon@gmail.com>,
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Subject: Re: [PATCH v3 2/6] branch.c: replace `git_config()` with `git_config_get_string()`
Date: Mon, 21 Jul 2014 10:59:21 -0700 [thread overview]
Message-ID: <xmqqiomqk2yu.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1405941145-12120-3-git-send-email-tanayabh@gmail.com> (Tanay Abhra's message of "Mon, 21 Jul 2014 04:12:21 -0700")
Tanay Abhra <tanayabh@gmail.com> writes:
> Use `git_config_get_string()` instead of `git_config()` to take advantage of
> the config-set API which provides a cleaner control flow.
>
> Signed-off-by: Tanay Abhra <tanayabh@gmail.com>
> ---
> branch.c | 24 ++++--------------------
> 1 file changed, 4 insertions(+), 20 deletions(-)
>
> diff --git a/branch.c b/branch.c
> index 46e8aa8..827307f 100644
> --- a/branch.c
> +++ b/branch.c
> @@ -140,33 +140,17 @@ static int setup_tracking(const char *new_ref, const char *orig_ref,
> return 0;
> }
>
> -struct branch_desc_cb {
> - const char *config_name;
> - const char *value;
> -};
> -
> -static int read_branch_desc_cb(const char *var, const char *value, void *cb)
> -{
> - struct branch_desc_cb *desc = cb;
> - if (strcmp(desc->config_name, var))
> - return 0;
> - free((char *)desc->value);
> - return git_config_string(&desc->value, var, value);
> -}
> -
> int read_branch_desc(struct strbuf *buf, const char *branch_name)
> {
> - struct branch_desc_cb cb;
> + const char *v = NULL;
> struct strbuf name = STRBUF_INIT;
> strbuf_addf(&name, "branch.%s.description", branch_name);
> - cb.config_name = name.buf;
> - cb.value = NULL;
> - if (git_config(read_branch_desc_cb, &cb) < 0) {
> + if (git_config_get_string(name.buf, &v)) {
> strbuf_release(&name);
> return -1;
> }
> - if (cb.value)
> - strbuf_addstr(buf, cb.value);
> + strbuf_addstr(buf, v);
> + free((char*)v);
In this cast, I smell an API mistake to insist an extra constness to
the output parameter of git_config_get_string() in [3/4] of the
previous series. Unlike the underlying git_config_get_value(),
which lets the caller peek into the internal cached copy, the caller
of git_config_get_string() is given its own copy, and I do not
offhand see a good reason to forbid the caller from modifying it.
> strbuf_release(&name);
> return 0;
> }
next prev parent reply other threads:[~2014-07-21 17:59 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-21 11:12 [PATCH v3 0/6] git_config callers rewritten with the new config cache API Tanay Abhra
2014-07-21 11:12 ` [PATCH v3 1/6] alias.c: replace `git_config()` with `git_config_get_string()` Tanay Abhra
2014-07-21 12:52 ` Matthieu Moy
2014-07-21 13:43 ` Ramsay Jones
2014-07-31 17:13 ` Samuel Bronson
2014-07-21 11:12 ` [PATCH v3 2/6] branch.c: " Tanay Abhra
2014-07-21 17:59 ` Junio C Hamano [this message]
2014-07-21 18:06 ` Matthieu Moy
2014-07-21 18:11 ` Tanay Abhra
2014-07-21 11:12 ` [PATCH v3 3/6] imap-send.c: replace `git_config()` with `git_config_get_*()` family Tanay Abhra
2014-07-21 18:00 ` Junio C Hamano
2014-07-21 11:12 ` [PATCH v3 4/6] notes.c: replace `git_config()` with `git_config_get_value()` Tanay Abhra
2014-07-21 11:12 ` [PATCH v3 5/6] pager.c: " Tanay Abhra
2014-07-21 11:12 ` [PATCH v3 6/6] notes-util.c: " Tanay Abhra
2014-07-22 11:23 ` Jeff King
2014-07-21 11:44 ` [PATCH/RFC] rewrite `git_default_config()` using config-set API functions Tanay Abhra
2014-07-21 13:43 ` Matthieu Moy
2014-07-21 14:23 ` Tanay Abhra
2014-07-21 15:37 ` Matthieu Moy
2014-07-21 18:07 ` Junio C Hamano
2014-07-22 7:55 ` Matthieu Moy
2014-07-21 13:59 ` Ramsay Jones
2014-07-21 12:51 ` [PATCH v3 0/6] git_config callers rewritten with the new config cache API Matthieu Moy
2014-07-21 13:15 ` Tanay Abhra
2014-07-21 13:45 ` Matthieu Moy
2014-07-21 14:00 ` Tanay Abhra
2014-07-21 14:27 ` Matthieu Moy
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=xmqqiomqk2yu.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=tanayabh@gmail.com \
/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.