We are on a Free plan workspace (alexionsoftware) that is close to the 1 GB limit, and we have been cleaning up. After the cleanup we see a large gap between what a fresh clone contains and what Bitbucket reports as the repository size, which as far as we understand means server-side garbage collection is needed.
Since Free plan workspaces cannot open a support ticket, I am posting here as suggested in similar threads.
What we did
Today we rewrote the history of the misc repository with git filter-repo, removing four directories that had not been used since 2020–2022, and we deleted two leftover refs/svn/* references from an old SVN migration. The rewritten history has been force-pushed and the repository now has a single branch.
What we measured
For each repository below, "fresh clone" means a git clone --mirror straight from Bitbucket, with every object repacked in one pass:
| Repository | Fresh clone, fully repacked | Reported by Bitbucket |
|---|
misc | 10.9 MB | 157.4 MB |
maatwerk | 26.7 MB | 93.2 MB |
alexion-crm | 198.3 MB | 314.3 MB |
On the Git LFS side, we compared the pointers before and after the rewrite of misc: it went from 247 pointers referencing 227.7 MB to 181 pointers referencing 148.4 MB. So 66 LFS objects totalling roughly 79 MB are no longer referenced by any branch or tag.
What happened after the force-push
This is the part that made us post. The rewrite itself landed correctly — a fresh clone of misc has an 11 MB .git/objects directory and none of the removed directories appear anywhere in its history. But the size Bitbucket reports for the repository did not go down:
misc | Size |
|---|
| Before the rewrite | 157.4 MB |
| After the force-push | 168 MB |
| A fresh clone, fully repacked | 10.9 MB |
It went up by roughly the size of the pack we pushed, which we read as: the pre-rewrite objects are all still being stored and counted alongside the new ones. That is understandable, but it does mean the cleanup currently costs us storage instead of saving it, and we have paused any further cleanup until we know it can actually be reclaimed.
What we would like to ask
1. Could you run server-side garbage collection on misc, maatwerk and alexion-crm in the alexionsoftware workspace? For misc this covers both the rewritten Git history and the unreferenced LFS objects.
2. Are closed pull requests holding on to objects here? I read in your documentation that support can confirm which pull requests need to be deleted to free storage. If that applies to these repositories, could you tell us which ones, so we can clean them up ourselves?
3. Is the gap above the expected behaviour? We would like to understand whether the difference between a fresh clone and the reported size is normal packing overhead, or whether it points at something we should be doing differently. It varies quite a bit per repository (1.2x, 3.5x and 1.6x), which we cannot explain from our side.
4. How long does reclaiming normally take? We have more cleanup we would like to do — another repository with unused branches and old migration references — but after seeing the size go up rather than down, we would rather wait until we know the space comes back. Knowing roughly what to expect would help us plan.
Happy to provide anything else that helps. Thanks in advance.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.