Cloning the repo pulls ~664 MB. Almost all of it is turbo's build cache, committed by accident and never removed.
Symptom
A fresh clone transfers ~664 MB and takes several minutes:
Receiving objects: 27% (7581/27819), 544.26 MiB | 1.76 MiB/s
664.08 MiB
GitHub reports the repo at 678513 KB (~662 MiB). The rate is not the client's connection — serving a pack that size is slow for everyone.
Cause
.turbo/cache/ is tracked on main: 7632 files, ~699 MiB.
Everything else in the entire history — all source, all docs, every commit ever made — is ~115 MiB. So the cache is ~86% of the repo.
It entered in a single commit:
118e6cad Tue Aug 18 18:15:07 2026 [The Framework] uncommitted changes
That is The Framework's own auto-commit. It swept up the untracked build cache because:
.gitignore has no .turbo entry, so the cache was never ignored, and- the auto-commit stages everything that is untracked, with no size or generated-artifact guard.
No commit has touched .turbo since, so the files sit on main exactly as they landed.
Worth noting: the repo does not even use turbo any more. There is no turbo.json tracked on main and no turbo dependency in the root package.json. The cache is dead weight from a build system that has already been removed.
It is easy to miss when browsing: .turbo/ is one collapsed folder row near the top of the GitHub file listing, and it gives no hint that it holds 7632 files.
Fix
Three parts. The first two are uncontroversial; the third needs a decision.
1. Ignore it. Add to .gitignore:
# turbo build cache
.turbo/
Note the .turbo/ directories under packages/* and examples/* are untracked but also unignored today — a trailing-slash pattern with no leading slash covers all of them.
2. Untrack it.
git rm -r --cached .turbo
This stops the bleeding but does not shrink clones. The 699 MiB stays in history, so git clone still transfers it.
3. Rewrite history — the only step that actually makes clones fast:
git filter-repo --path .turbo --invert-paths
This drops the repo to roughly 115 MiB of blob data. It rewrites every commit hash and requires a force-push, which invalidates existing clones — everyone re-clones once and open PRs need rebasing.
Recommendation: do it. The project is unreleased with no users, the contributor count is small, and the cost is one coordinated re-clone versus every future clone paying ~660 MB. Timing should be agreed first so nobody force-pushes over in-flight work.
Follow-up
The underlying bug is in The Framework, not in this repo's config: the auto-commit path committed 699 MiB of generated build cache without complaint. A .gitignore entry fixes this instance; it does not stop the next one. The auto-commit should refuse or warn on obviously generated artifacts — a size threshold, a known-cache-directory list, or both. Happy to open that separately if it should be tracked on its own.
🤖 curated
Cloning the repo pulls ~664 MB. Almost all of it is turbo's build cache, committed by accident and never removed.
Symptom
A fresh clone transfers ~664 MB and takes several minutes:
GitHub reports the repo at 678513 KB (~662 MiB). The rate is not the client's connection — serving a pack that size is slow for everyone.
Cause
.turbo/cache/is tracked onmain: 7632 files, ~699 MiB.Everything else in the entire history — all source, all docs, every commit ever made — is ~115 MiB. So the cache is ~86% of the repo.
It entered in a single commit:
That is The Framework's own auto-commit. It swept up the untracked build cache because:
.gitignorehas no.turboentry, so the cache was never ignored, andNo commit has touched
.turbosince, so the files sit onmainexactly as they landed.Worth noting: the repo does not even use turbo any more. There is no
turbo.jsontracked onmainand no turbo dependency in the rootpackage.json. The cache is dead weight from a build system that has already been removed.It is easy to miss when browsing:
.turbo/is one collapsed folder row near the top of the GitHub file listing, and it gives no hint that it holds 7632 files.Fix
Three parts. The first two are uncontroversial; the third needs a decision.
1. Ignore it. Add to
.gitignore:Note the
.turbo/directories underpackages/*andexamples/*are untracked but also unignored today — a trailing-slash pattern with no leading slash covers all of them.2. Untrack it.
This stops the bleeding but does not shrink clones. The 699 MiB stays in history, so
git clonestill transfers it.3. Rewrite history — the only step that actually makes clones fast:
This drops the repo to roughly 115 MiB of blob data. It rewrites every commit hash and requires a force-push, which invalidates existing clones — everyone re-clones once and open PRs need rebasing.
Recommendation: do it. The project is unreleased with no users, the contributor count is small, and the cost is one coordinated re-clone versus every future clone paying ~660 MB. Timing should be agreed first so nobody force-pushes over in-flight work.
Follow-up
The underlying bug is in The Framework, not in this repo's config: the auto-commit path committed 699 MiB of generated build cache without complaint. A
.gitignoreentry fixes this instance; it does not stop the next one. The auto-commit should refuse or warn on obviously generated artifacts — a size threshold, a known-cache-directory list, or both. Happy to open that separately if it should be tracked on its own.🤖 curated