From: Junio C Hamano <gitster@pobox.com>
To: Paul Tan <pyokagan@gmail.com>
Cc: Git List <git@vger.kernel.org>,
Stefan Beller <sbeller@google.com>,
Johannes Schindelin <johannes.schindelin@gmx.de>,
Stephen Robin <stephen.robin@gmail.com>
Subject: Re: [PATCH v2 02/19] parse-options-cb: implement parse_opt_pass_argv_array()
Date: Wed, 10 Jun 2015 01:03:54 -0700 [thread overview]
Message-ID: <xmqqy4jst2fp.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CACRoPnRVjNseXPOxKe4_3rnKXmAYeA80iCHY3o8euWA=EUX6hA@mail.gmail.com> (Paul Tan's message of "Wed, 10 Jun 2015 15:11:01 +0800")
Paul Tan <pyokagan@gmail.com> writes:
> I don't see how it feels iffy.
That is largely a taste thing. And a good taste matters.
What is iffy is to use strbuf as an external interface between the
implementation of the parse_opt_pass() API function and its users.
I would expect that no users of the parse_opt_pass() would ever take
advantage of the fact that the value they are using is implemented
as a strbuf, allowing them to use the family of functions in the
strbuf API to further manipulate it. All users you added wants to
use a plain vanilla string, and only because you used strbuf as the
interface element, they have to say "var.buf" to get to the value
they want to use.
> The purpose of using strbufs (and
> argv_arrays) is to avoid error-prone manual memory management.
It is a good idea to use strbuf as an implementation detail of
parse_opt_pass() function. After all, safer, easier and efficient
manipulation of strings is why we added the strbuf API to the system
in the first place.
But it is a different matter to expose that as an API element when
the recipient is not going to benefit.
In other words, callers of the API designed with a better taste
would look more like this:
static const char *opt_diffstat;
static struct option pull_options[] = {
...
{ OPTION_CALLBACK, 'n', NULL, &opt_diffstat, NULL,
N_("do not show a diffstat at the end of the merge"),
PARSE_OPT_NOARG | PARSE_OPT_NONEG, parse_opt_pass
},
...
};
static int run_merge(void)
{
...
if (opt_diffstat)
argv_array_push(&args, opt_diffstat);
...
}
That way, they do not have to define strbuf variables and
dereference the value as opt_diffstat.buf.
And the implementation of the API element is not all that different
from what you wrote:
int parse_opt_pass(const struct options *opt, const char *arg, int unset)
{
struct strbuf sb = STRBUF_INIT;
char **value = opt->value;
if (*value)
free(*value);
if (opt->long_name) {
strbuf_addf(&sb, "--%s%s",
unset ? "no-" : "",
opt->long_name);
...
}
...
*value = strbuf_detach(&sb, NULL);
return 0;
}
next prev parent reply other threads:[~2015-06-10 8:04 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-03 6:48 [PATCH v2 00/19] Make git-pull a builtin Paul Tan
2015-06-03 6:48 ` [PATCH v2 01/19] parse-options-cb: implement parse_opt_pass_strbuf() Paul Tan
2015-06-09 23:11 ` Junio C Hamano
2015-06-03 6:48 ` [PATCH v2 02/19] parse-options-cb: implement parse_opt_pass_argv_array() Paul Tan
2015-06-03 16:56 ` Stefan Beller
2015-06-09 23:16 ` Junio C Hamano
2015-06-10 7:11 ` Paul Tan
2015-06-10 8:03 ` Junio C Hamano [this message]
2015-06-03 6:48 ` [PATCH v2 03/19] argv-array: implement argv_array_pushv() Paul Tan
2015-06-03 6:48 ` [PATCH v2 04/19] pull: implement skeletal builtin pull Paul Tan
2015-06-10 0:23 ` Junio C Hamano
2015-06-03 6:48 ` [PATCH v2 05/19] pull: implement fetch + merge Paul Tan
2015-06-09 23:27 ` Junio C Hamano
2015-06-03 6:48 ` [PATCH v2 06/19] pull: pass verbosity, --progress flags to fetch and merge Paul Tan
2015-06-09 23:36 ` Junio C Hamano
2015-06-03 6:48 ` [PATCH v2 07/19] pull: pass git-merge's options to git-merge Paul Tan
2015-06-03 6:48 ` [PATCH v2 08/19] pull: pass git-fetch's options to git-fetch Paul Tan
2015-06-03 17:16 ` Stefan Beller
2015-06-03 6:48 ` [PATCH v2 09/19] pull: error on no merge candidates Paul Tan
2015-06-09 23:56 ` Junio C Hamano
2015-06-13 5:52 ` Paul Tan
2015-06-03 6:48 ` [PATCH v2 10/19] pull: support pull.ff config Paul Tan
2015-06-09 23:59 ` Junio C Hamano
2015-06-03 6:48 ` [PATCH v2 11/19] pull: check if in unresolved merge state Paul Tan
2015-06-10 1:29 ` Junio C Hamano
2015-06-10 14:38 ` Junio C Hamano
2015-06-10 15:12 ` Paul Tan
2015-06-10 17:14 ` Junio C Hamano
2015-06-14 7:44 ` Paul Tan
2015-06-03 6:48 ` [PATCH v2 12/19] pull: fast-forward working tree if head is updated Paul Tan
2015-06-03 6:48 ` [PATCH v2 13/19] pull: implement pulling into an unborn branch Paul Tan
2015-06-10 1:31 ` Junio C Hamano
2015-06-03 6:48 ` [PATCH v2 14/19] pull: set reflog message Paul Tan
2015-06-03 6:48 ` [PATCH v2 15/19] pull: teach git pull about --rebase Paul Tan
2015-06-10 1:56 ` Junio C Hamano
2015-06-10 7:55 ` Paul Tan
2015-06-10 14:44 ` Junio C Hamano
2015-06-10 15:35 ` Paul Tan
2015-06-10 16:13 ` Junio C Hamano
2015-06-10 23:02 ` Junio C Hamano
2015-06-03 6:49 ` [PATCH v2 16/19] pull: configure --rebase via branch.<name>.rebase or pull.rebase Paul Tan
2015-06-03 6:49 ` [PATCH v2 17/19] pull --rebase: exit early when the working directory is dirty Paul Tan
2015-06-03 10:27 ` Kevin Daudt
2015-06-10 5:53 ` Kevin Daudt
2015-06-03 6:49 ` [PATCH v2 18/19] pull --rebase: error on no merge candidate cases Paul Tan
2015-06-03 17:38 ` Stefan Beller
2015-06-03 6:49 ` [PATCH v2 19/19] pull: remove redirection to git-pull.sh Paul Tan
2015-06-03 17:49 ` Stefan Beller
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=xmqqy4jst2fp.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=johannes.schindelin@gmx.de \
--cc=pyokagan@gmail.com \
--cc=sbeller@google.com \
--cc=stephen.robin@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.