We're on the Bitbucket Cloud Free plan (workspace: hooke-solutions). On 2026-07-13 we rewrote a repository's history with git filter-repo to remove ~1.2GB of dead historical blobs (superseded pickle files, old debug images) and force-pushed the result to origin. The repo's true size dropped from ~953.9MB to ~784MB.
Two weeks later, the workspace storage dashboard is still reporting the old pre-rewrite size (953.76MB), unchanged to the decimal, across multiple days of checking.
We've independently re-verified the rewrite is correct and complete from the client side:
- git ls-remote --heads --tags origin: 88 refs total (85 branches + 3 tags) — all accounted for, nothing suspiciously missing or stale.
- A fresh git clone --mirror of the entire remote (all 88 refs): 785MB total.
- git count-objects -vH inside that mirror: exactly one packfile, 784.23 MiB, zero loose objects, zero garbage.
So every ref Bitbucket currently advertises is small and already compacted — there's nothing on our end that should still be inflating the reported size. We understand storage stats can lag in the UI, but two weeks (well past the ~2-week figure we'd seen referenced) feels past normal caching behavior at this point.
Since Free-tier workspaces aren't eligible for a formal support ticket, we're hoping someone here has seen this before, or a Bitbucket staff member can take a look. Is there a known mechanism (e.g. server-side garbage collection, or stale references from historical pull requests pointing at pre-rewrite commit SHAs) that could keep the dashboard pinned at the old number even after a clean force-push? Any pointers on how to get this reconciled would be appreciated.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.