Today I cloned the repo and was surprised by the overall size and duration of the clone, so I asked Claude to have a look around, and give some suggestions. Here is what it founds:
The short version: we could roughly halve clone size by asking GitHub to repack the repo. It needs no history rewrite, and no commit hashes change.
GitHub reports the repo at about 483 MB, but it isn't full of junk. Most of the waste comes from poor compression: git stores file versions as deltas, and ours are badly chained.
As a test, I made a fresh bare clone and ran git repack -a -d -f --depth=250 --window=250 on it. The pack went from 371 MB to 189 MB.
The cause is a few large files we edit constantly. Git's default delta depth of 50 doesn't keep up with thousands of versions:
| File | Versions | Disk now | After repack |
|---|---|---|---|
design.md (1.6 MB) |
3,033 | 28.1 MB | 1.8 MB |
src/check/Check.zig |
2,271 | 25.8 MB | 2.9 MB |
src/postcheck/monotype/lower.zig |
2,106 | 22.5 MB | 3.6 MB |
src/check/checked_artifact.zig |
1,454 | 21.2 MB | 1.5 MB |
roc-lang/roc. It's a support request on their side, and it costs contributors nothing.design.md into a few smaller files. It has had about 2,700 commits this year alone. Smaller files would compress better and be easier to review, and they'd keep this from creeping back.I'm not proposing a history rewrite. Some old binaries are still in history (examples/cli/file, ci/sccache, a few .mov demos), but they only add up to about 25–30 MB. Removing them isn't worth breaking every fork and open PR.
You don't need to wait for GitHub on this part. Running these locally took my .git from 488 MB to 227 MB:
git gc --aggressive --prune=now
git maintenance start
Thanks for looking into this @Matthieu Pizenberg. The proposals sound good, can you make issues for them?
Last updated: Nov 04 2026 at 18:54 UTC