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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Mar 7, 2026, 01:34 UTC
Message-ID: <aauAjQhhh7pxIxjD@fruit.crustytoothpaste.net>
In-Reply-To: <CAK7947n9gqhRoykNUR4NvPFiaCB4nuotxQTT=eftSF8O9ZO2rg@mail.gmail.com>

On 2026-03-07 at 00:29:18, Mike Banon wrote:

Show 16 quoted lines

> 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