Re: [PATCH] clone, progress: add --no-turtle-speed option to abort slow clones

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 2842 bytes --]

On 2026-03-07 at 00:29:18, Mike Banon wrote:
> Brian, thank you very much for your code review!
> 
> This problem has been happening to me for a couple of weeks while
> using GitHub: as a part of my "floppinux-amd64net" pet project (2.88
> MB Linux floppy image with Ethernet/WiFi – for putting into a coreboot
> BIOS image), I wrote a large [1] script that clones a lot of GitHub
> repositories and builds everything from scratch. With some non-zero
> probability (floating between 5%–30% depending on day/location and
> other unknown factors), my git clone operation gets directed to a
> really slow Git server with around ~70 KiB/s download speed, which is
> especially painful if it tries to clone some large repo like a
> linux-firmware. But if I terminate that git clone and start it again,
> there is a good chance that my next connection will be fast (at least
> a few MiB/s). So with the bash code like [2] below – in case of a slow
> connection, it will simply restart until it gets a fast server and
> clones successfully.

GitHub doesn't throttle speeds once the operation starts, although it
sometimes does delay the _start_ of an operation if there's excessive
use (for example, if you're cloning the same repository too many times,
as in some automated systems).  GitHub wants the operation to complete
as quickly as possible once it starts because a clone or fetch will take
the same CPU and memory resources no matter how long it's running and
obviously freeing those resources faster is better than consuming them
for longer periods (since then they can be used for other users).

If you're seeing this, I'd recommend opening a ticket at GitHub and
including the output at https://github-debug.com/, since that will be
helpful in troubleshooting the problem.  For instance, it may be that
there's a bad connection between your ISP and GitHub and that can be
addressed.  Or, if there is an overloaded server impacting things, that
would be a thing that GitHub would want to look into.

If you can capture the problem with `GIT_TRACE=1 GIT_TRANSFER_TRACE=1
GIT_CURL_VERBOSE=1` before your Git command and you include that output
and the repository you're having problems with, then that will allow
GitHub to look up the request by its ID and find what's going on.

My participation in the list from this email address is in my personal
capacity and my personal capacity alone, but I do work on the Git
services at GitHub and obviously we want everyone to have a good
experience provided they're using a reasonable amount of resources and
otherwise behaving appropriately.

Of course, I think people would still find the `--min-speed` patch
useful, but my hope is that it's not a feature you'll need to make use
of.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]