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.
Hi @hakemcpu ,
I have attempted to reduce the size of that repository, but the size has not been reduced.
You have a couple of options to resolve this:
Option 1 - Delete & recreate the repositories
This is the fastest way to solve the problem, but loses metadata such as PRs, Pipelines, Permissions, etc.
Perform a clone of those repositories for backup purposes
Delete those repositories 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.
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
Perform cleanup operations locally to reduce the size
Once complete, push those repositories 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.
Option 2 - Temporarily upgrade
Upgrade to a paid plan and utilise our 30-day trial period to restore functionality and provide more time to reduce your repository directly without deletion. You can choose to continue or cease your trial before the end of the 30-day period.
If you encounter any issues during this period - you may raise a ticket directly with our support team using your workspace URL: Atlassian Support
Please let me know how this goes.
Cheers!
- Ben (Bitbucket Cloud Support)
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.