Request for Manual Garbage Collection - Repository Size Not Reducing After LFS Migration

Question

Hi everyone,

I am looking for assistance with reducing my Bitbucket Cloud repository size. I have recently migrated several large files to Git LFS and performed a full history rewrite using
```git lfs migrate import --include="pipelines/**/data/*.zip" --everything --verbose``` and then ```git push --all --force```

Steps taken:

Rewrote history to convert large files into LFS pointers.

Verified locally that the repository size has decreased significantly i.e. 349mb with

GIT_LFS_SKIP_SMUDGE=1 git clone <repo-url> and otherwise 932Force-pushed the changes to Bitbucket Cloud.

The Issue:
Despite these steps, the repository size shown in the Bitbucket UI has not decreased. I understand that Bitbucket Cloud may be retaining internal references (such as pull request diffs or auto-merges) that keep the old large objects reachable, preventing the automated garbage collection from pruning them.

Since I am on a Free plan and cannot trigger a manual GC myself, could a Support Engineer please help by:

Identifying and removing internal references to the old, rewritten commits.

Manually running garbage collection (GC) on this repository.

Repository URL: https://bitbucket.org/manualcreator/manualcreator_scripts

I am aware that this process may result in the loss of historical pull request data (diffs/comments) associated with the rewritten commits and I am okay with that.

Thank you for your help!

Ben · Answer

Hi! I've attempted to execute a server-side gc on your largest repository, but it has not reduced the size. The most common reason is that some large binary files were missed, or are being retained due to pull requests which are present in your repository (these can't be targetted by gc). 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://@bitbucket.org//.git SSH git push --mirror git@bitbucket.org:/.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 trial period to restore functionality and provide more time to reduce your repository directly without deletion. * If you encounter any issues during this period - you may raise a ticket directly with our support team using your workspace URL: Atlassian Support Cheers! - Ben (Bitbucket Cloud Support)

Prasanna Ravichandran · Answer

Hi,

If the repository size is still not reducing after cleanup, it is usually because old Git objects and pull request references are still retained on the Bitbucket server.
In such cases, Atlassian support may need to run a manual garbage collection (GC) on the repository.
You can also verify locally using git count-objects -vH and ensure large files/history were fully removed before requesting support assistance. Hope this helps. Thanks