Run server-side gc after history rewrite — repo size not reflecting reduction

[hakemcpu]

Hi,

I rewrote the history of my repository to reduce its size (removed large superseded binary blobs and dead vendored directories using git filter-repo, then force-pushed). The cleanup is complete on my end, but the repository's
accounted size hasn't dropped and is still close to the 1 GB workspace limit.

- Workspace: hzaied
- Repository: holyquran_v1 (hzaied/holyquran_v1)
- Default branch: mainline

Evidence the content is already reduced:
- A fresh git clone --mirror of the repo is ~255 MB (all reachable content).
- The Bitbucket API (GET /2.0/repositories/hzaied/holyquran_v1) still reports size = ~599 MB.

The ~344 MB gap is unreachable objects from the old history (and likely stale refs/pull-requests/* refs pinning old commits) that haven't been garbage-collected.

Request:
1. Please run server-side garbage collection on this repository so the accounted size reflects the actual ~255 MB of reachable content.
2. Please clear any stale pull-request refs holding onto the old (pre-rewrite) commits.

The repository now has a single branch (mainline) and all old branches have been deleted, so there should be no reachable references to the removed objects.

[Ajay _view26_]

Hi @hakemcpu ,

This is a very common situation after running git filter-repo — you've done the cleanup locally and pushed it, but the server-side still holds onto the old objects until garbage collection runs.

Unfortunately, Bitbucket Cloud doesn't expose a self-serve GC trigger for repos under the 4 GB limit. The automatic GC only kicks in when a repo goes over the 4 GB limit and you push a reset.

The good news is that your situation is well-understood by Atlassian support and they do manually run git gc on repos when asked.

The typical path is to raise a support ticket through support.atlassian.com with your workspace and repo details.