Repository size not reduced after history rewrite — request server-side garbage collection

[Greg Marsh]

Hi Bitbucket team,

We're on a free workspace (so we can't open a support ticket) and would appreciate help from a Bitbucket engineer.

Workspace: carpetcall-au

Repository: carpetcall-au/carpet-call

What we did: Several large binary files had been accidentally committed to this repo years ago and later deleted, but remained in history — chiefly pub/media07_12.zip (~823 MB), plus pub/media02_11.zip, pub/media.zip, app/code/Mageplaza.zip, and a ~20 MB core dump. On 2026-07-17 we rewrote history with git-filter-repo to remove them from all history, and force-pushed all branches.

Result on the client side: A fresh git clone --mirror of the repository is now ~64 MB, down from ~946 MB. All ~217 branches and 2,500+ commits are preserved, and none of the removed files are reachable from any branch ref.

The problem: 5 days later, our workspace still reports as near the 1 GB limit and shows the "close to 1 GB size limit" warning on every push. The freed space has not been reclaimed.

What I've verified: The old, pre-rewrite commits are still present on the server. Fetching the old master tip by SHA (c9c29778b249b23c737a8250efa2ed4576ff13ed) — which no branch points to anymore — still succeeds, so the old objects remain reachable server-side (I believe they're anchored by retained pull-request refs). A git push --mirror --force was already performed, and it's well past the usual async-GC window, so the unreachable/old-PR-anchored objects aren't being collected on their own.

Request: Could a Bitbucket engineer please run garbage collection / repack on carpetcall-au/carpet-call to reclaim the storage from the old objects, and confirm the updated repository and workspace size afterward?

Thanks very much!