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!

[Vipul Reddy]

Hey @Greg Marsh, thanks for the details.

I've run a GC on said repository; however, the size of the repo still remains at ~941.8MB; it hasn't changed very much.

The other option you could consider is to delete and recreate the repository. This is the fastest way to solve the problem, but loses metadata such as PRs, Pipelines, Permissions, etc:

1. Perform a clone of the repository for backup purposes

2. Delete the repository from your workspace to free up space and allow you to push. NOTE: This will permanently remove metadata such as PR's/pipelines/user permissions etc.

3. Identify the largest files in your repositories by executing the following command:
   git rev-list --objects --all \
   | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' \| awk '/^blob/ {print substr($0,6)}' \
   | sort -r --numeric-sort --key=2 \
   | numfmt --field=2 --to=iec-i --suffix=B --padding=7 --round=nearest

4. Perform cleanup operations locally to reduce the size

5. Once complete, push the repository back to your workspace by creating a blank repository with the same name of the deleted repository, then mirror pushing the contents of the cleaned repository:

HTTPS
git push --mirror https://<username>@bitbucket.org/<WorkspaceID>/<RepoName>.git
SSH
git push --mirror git@bitbucket.org:<WorkspaceID>/<RepoName>.git

NOTE: This will remove metadata such as PR's/pipelines/permissions etc but will keep your commit history and binary files intact.

Let me know if you have any other questions. Thanks.

[Tomislav Tobijas]

Hi @Greg Marsh ,

I've pinged the official forum support team. Someone should get back to you within 1-2 business days. 👀

Cheers,
Tobi