#56 repo.git is 260 files / 226 loose objects (Pages 20k-file cap, dumb clone = 1 GET per object)
Follow-up to #55 (same root cause, different symptom). The export path produces a bloated multi-file artifact.
Measured on this repo (318 tracked files):
today (git clone --bare): files=260 du=2.2M loose=226 packs=3
bundled (clone from .bundle): files=24 du=796K loose=0 packs=1
Two costs:
- Dumb HTTP fetches loose objects one request each: a clone of the current export issues 200+ GETs for a toy repo. Great for nobody, pathological on a high-latency link.
- Cloudflare Pages free tier limits a deployment to 20,000 files and 25 MiB per file. A mid-size repo (thousands of commits, loose objects) exceeds the file cap and the deploy fails outright. This is the exact target platform for the dumb-clone design.
Same fix as #55: build repo.git from the existing repo.bundle, which yields exactly one pack and no loose objects.
Verified: packed-only export + update-server-info serves and clones correctly (git clone -b master http://127.0.0.1:39401/repo.git -> tip matches).
Acceptance:
-
a build's
repo.gitcontains exactly 1.packand 0 loose objects (git count-objects -vshowscount: 0) -
total file count under
repo.gitstays < 40 for the fixture repo (hooks/description noise removed) -
git clone <origin>/repo.gitstill works overhu13 serve - docs state the Pages limits and that a single pack keeps us under them
Uunknown ·
Fixed in e2792258-fd01-4be6-83ca-c68ef435cfed: export now clones from repo.bundle (one pack, no loose/dangling objects), remote.origin removed, sample hooks removed, single run_git_opt runner with OsStr paths + 120s export budget, content-type anchored to .git/HEAD+info/, docs updated. tests/clone_export.rs asserts all of it.