Repository navigation
Further optimize Git clones #865
Description
Activity
- added a parent issue
on Aug 19, 2026 - removed a parent issue
on Aug 19, 2026 - added a sub-issue
on Aug 19, 2026 I tried various settings that did not yield significant improvements:
core.fscache=true(Windows only): no change on try. The Windows workers already have it in the system gitconfig.core.compression=0: no change locally or on try, on either platform. The pack is built by the server and stored as received, so the client's compression level never applies to a clone.core.fsync=none: no change anywhere.http.postBuffer=1024M: no change. It sizes the upload buffer, and a fetch uploads very little.fetch.unpackLimit=1: no change, every fetch already lands as a pack.index.version=4: halves the index file (70 MB to 39 MB on a 466k entry no cone sparse index) with no measurable time change.--filter=blob:nonefor full checkouts: much slower, measured locally on Windows only. The checkout hands one blob hash per path togit fetch --stdin, and the client spent about three minutes on that list before sending the request.- bundle URIs: incompatible with
--depth, so unusable with shallow clones.
- added a sub-issue
on Sep 15, 2026
We started using shallow clones in Gecko to get clone times down to ~2 minutes, but I think there are further optimizations we can make. Marco recently shared this article which contains a bunch of tips:
https://about.gitlab.com/blog/supercharge-your-git-workflows/
I won't have time to prioritize this, so filing an issue to track it for now.