From: "René Scharfe" <l.s.r@web.de>
To: Patrick Steinhardt <ps@pks.im>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH] remote-curl: simplify passing of push specs
Date: Wed, 15 Jul 2026 17:39:51 +0200 [thread overview]
Message-ID: <3b29757e-abcd-4235-a829-ea67c19e71d0@web.de> (raw)
In-Reply-To: <alcrhGUCVMCnm2-i@pks.im>
On 7/15/26 8:41 AM, Patrick Steinhardt wrote:
> On Wed, Jul 15, 2026 at 06:41:17AM +0200, René Scharfe wrote:
>> diff --git a/remote-curl.c b/remote-curl.c
>> index 9e614c5567..2c35dd5240 100644
>> --- a/remote-curl.c
>> +++ b/remote-curl.c
>> @@ -1340,10 +1340,9 @@ static void parse_get(const char *arg)
>> fflush(stdout);
>> }
>>
>> -static int push_dav(int nr_spec, const char **specs)
>> +static int push_dav(const char **specs)
>> {
>> struct child_process child = CHILD_PROCESS_INIT;
>> - size_t i;
>>
>> child.git_cmd = 1;
>> strvec_push(&child.args, "http-push");
>
> I wonder whether the interface would be even better if we simply passed
> around a `const struct strvec *` directly. That makes it explicit what
> kind of guarantees we have, and all transitive callers already have one
> available anyway.
You mean that passing a managed array instead of a plain NULL-terminated
one would make more places visibly safer at almost no cost?
>> @@ -1353,15 +1352,14 @@ static int push_dav(int nr_spec, const char **specs)
>> if (options.verbosity > 1)
>> strvec_push(&child.args, "--verbose");
>> strvec_push(&child.args, url.buf);
>> - for (i = 0; i < nr_spec; i++)
>> - strvec_push(&child.args, specs[i]);
>> + strvec_pushv(&child.args, specs);
>
> I thought that we had something like `strvec_pushvec()` that knew to
> also optimize for this case so that we don't have to reallocate the
> vector multiple times. And if we had that function it would even be more
> efficient to pass it down the stack. But we seemingly don't have it, so
> that argument is kind of moot.
We could add one. Not sure it would make a measurable difference; if
the number of specs is huge there are probably other costs that dwarf
pushing them to a strvec.
I have to admit that the simplicity of strvec_pushv() nudged me towards
using a NULL-terminated array here, though. So just having a
strvec_pushvec() available could guide towards using the length-limited
strvec instead of a simpler NULL-terminated array (which explodes if
left unterminated).
René
prev parent reply other threads:[~2026-07-15 15:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 4:41 [PATCH] remote-curl: simplify passing of push specs René Scharfe
2026-07-15 6:41 ` Patrick Steinhardt
2026-07-15 15:39 ` René Scharfe [this message]
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=3b29757e-abcd-4235-a829-ea67c19e71d0@web.de \
--to=l.s.r@web.de \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox