From: "Randall S. Becker" <rsbecker@nexbridge.com>
To: "'Jeff King'" <peff@peff.net>, "'Junio C Hamano'" <gitster@pobox.com>
Cc: "'Xia XiaoWen'" <haoyurenzhuxia@gmail.com>, <git@vger.kernel.org>,
<worldhello.net@gmail.com>,
"'Xia XiaoWen'" <chenan.xxw@alibaba-inc.com>
Subject: RE: [PATCH] add http.maxReceiveSpeed to limit git-receive-pack receiving speed
Date: Fri, 20 Aug 2021 14:21:28 -0400 [thread overview]
Message-ID: <018c01d795f0$350a5c00$9f1f1400$@nexbridge.com> (raw)
In-Reply-To: <YR/wbWhei0PPLSgX@coredump.intra.peff.net>
On August 20, 2021 2:12 PM, Jeff King wrote:
>On Thu, Aug 19, 2021 at 11:28:53AM -0700, Junio C Hamano wrote:
>
>> > https protocol, and only supports libcurl 7.15.5 and above.
>>
>> We are likely be raising the floor versions of libcURL to 7.16.0 or
>> even 7.19.4 soonish. It probably would make it easier to allow it
>> unconditionally (otherwise you'd probably need to implement error or
>> warning messages when configuration is given but the libcURL version
>> used is too old, etc.).
>
>Yeah, I agree that if we can drop the conditional totally, we should.
>
>If we do need to make it conditional, I think there was a preference for shifting to checking the actual option constants, like:
>
> #ifdef CURLOPT_MAX_RECV_SPEED_LARGE
> ...ok, we have it...
> #endif
>
>The rest of your comments all seemed quite reasonable to me.
>
>As a general feature, IMHO speed-limiting is best done outside of application-level tools like Git (and instead done via proxies or kernel
>network config). But since we are not building the feature ourselves, but rather just plugging our config to curl's feature, I don't have any
>problem with it here.
I second that. This should be in the realm of QoS at a managed switch/router in the consumer's network (or the upstream repo in some cases).
-Randall
next prev parent reply other threads:[~2021-08-20 18:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-19 9:14 [PATCH] add http.maxReceiveSpeed to limit git-receive-pack receiving speed Xia XiaoWen
2021-08-19 9:36 ` Bagas Sanjaya
2021-08-19 11:27 ` Xiaowen Xia
2021-08-19 18:28 ` Junio C Hamano
2021-08-20 18:11 ` Jeff King
2021-08-20 18:21 ` Randall S. Becker [this message]
2021-08-21 3:19 ` Xiaowen Xia
2021-08-21 4:21 ` Junio C Hamano
2021-08-21 5:16 ` Xiaowen Xia
2021-08-23 16:04 ` [PATCH v2] http: add http.maxReceiveSpeed to limit receiving speed of "git-receive-pack" chenan.xxw
2021-08-24 0:31 ` Jiang Xin
2021-08-31 4:15 ` Xiaowen Xia
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='018c01d795f0$350a5c00$9f1f1400$@nexbridge.com' \
--to=rsbecker@nexbridge.com \
--cc=chenan.xxw@alibaba-inc.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=haoyurenzhuxia@gmail.com \
--cc=peff@peff.net \
--cc=worldhello.net@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).