@jbygden The schedule for garbage collection is somewhat dynamic.

We originally ran a gc on every push. However that can be expensive for larger repos and so the frequency was tied to several repo properties, including push frequency and size.

Furthermore, we don't run git gc --prune=now and so a gc run does not necessarily remove (all) unreferenced objects. This is necessary as some of Bitbucket's internal processes rely on unreferenced objects having a grace period.

Wouldn't it be easier for you to implement a "Force GC/Prune"-button on the control panel for each repository, instead of all of us creating support issues every time?

Yes, possibly. We've been reluctant to do so because of the cost involved in running gc's. We do have this button internally and that is what our support engineers use when you contact them.

I sent an email to support@bitbucket.org. I got an automated reply telling me to use https://support.atlassian.com.

The way that is currently set up I believe is that people who have an existing account on support.atlassian.com can email directly. The system uses the email's sender address to look up the user account. However, if you do not have an account already this will not work.

Would you mind informing all of us when (or at what interval) this automated GC is run?

Wouldn't it be easier for you to implement a "Force GC/Prune"-button on the control panel for each repository, instead of all of us creating support issues every time?

I'd like this done as well, and followed the information in another of the cases about this - i.e. I sent an email to support@bitbucket.org. I got an automated reply telling me to use https://support.atlassian.com. Does that mean noone will read my request (and subsequently help me) at support@bitbucket.org?

Just experienced this as well, ironically while trying to reduce the repository size. After pushing the rewritten history, I came right up against the 2GB limit.

I also agree this is something that would be nice to expose under the repository Settings section.

@bugsy We put up a warning warning banner when you cross 1GB with the intention that that should give people a lot of leeway before getting to the point of being able to push anymore at 2GB. The encouragement here is to not continue with the warnings on the repo, but instead make an effort to get it back under 1GB.

However, there is the possibility of a single push bringing a repo from < 1GB to > 2GB and in that case you'd be locked out without prior warning. If this happened to you, I can help you out.

Can you email us at support@bitbucket.org with the repo details and in the email mention this comment?

Actually, even better would be a simple button to invalidate the reflog and run the GC straight from the repo's settings. Erasing the reflog silently might not be preferable.

This is actually really crucial. Ironically, a repository that I'm administrating hit the 2GB limit because I pushed a new root with none of the history and the server-side repo didn't reclaim all the unused blobs. Now I can't push at all, and I'm forced to move to a fresh repo. Even if I waited the standard 30 days (which is not an option for my team) for the reflog to expire, git gc would not run, because it requires a push (to a now read-only repo).

Therefore I second tader's request. This should be minor; I could even supply a hook script if you needed it.

Removing component: repository (automated comment)

Thanks for letting us know!
We're not low on disk space, so we'll just let Git deal with it on its own when the objects become eligible for automatic garbage collection.

Erik