Git LFS Pointers Persisting After File Removal and "git lfs prune", Causing Unexpected Large Repository Size in Bitbucket

Question

I'm encountering a persistent issue with Git LFS in my Bitbucket repository where deleted LFS-tracked files seem to leave behind pointer data, causing the repository size to remain significantly larger than expected, even after running git lfs prune. I've followed the standard procedures for removing LFS files, but the problem persists.

My repository was growing quite large due to a significant number of LFS-tracked files. The .gitattributes file correctly identifies these files for LFS tracking (e.g., *.jpg filter=lfs diff=lfs merge=lfs -text, *.mp4 filter=lfs diff=lfs merge=lfs -text).

I decided to remove a large number of old, unnecessary image and video files (approximately 5GB worth of LFS objects).

I expected the repository size on Bitbucket to decrease significantly after pushing these changes, reflecting the removal of the 5GB of LFS objects. But, the repository size on Bitbucket decreased slightly, but remained much larger than expected. It's as if the LFS objects were still present, or at least, a significant portion of their data was.

I ran git lfs prune locally to remove any unreferenced LFS objects:

git lfs prune

I've exhausted the standard troubleshooting steps I'm aware of. I'm hoping to avoid having to create a completely new repository and migrate the history, as that would be a significant disruption.

Answer 1

Bitbucket sometimes experiences issues where LFS objects remain even after they've been "removed" by commits, even after the forced push above. This is less likely now, but has been reported in the past.

To fix this, go to your repository settings on Bitbucket and look for an "LFS" section (location may vary).

When your there, there may be an option for simply viewing and managing LFS objects, perhaps with a button to "prune" or "clean up" orphaned objects on the server's side. This use may be available from the UI, but less often today.

The expectation is usually that pruning is client's side (then force push) and the server will cleanup automatically.

---

But, if you clearly can't find any LFS management tools in the UI, and a forced push of all branches/tags didn't fix the size issue, this strongly signals a possible issue with Bitbucket's backend.

If you want to contact BitBucket Support, you can clearly explain the steps you've taken, including the git lfs prune and --force --all pushes. Also provide your repository details. They have access to tools that can identify and remove the orphaned LFS objects on their servers.

This is the best solution in this case. They are prepared to analyze and fix problems on the server itself.