question about verification of lfs removal from remote repo

[Louis-26]

I've already push the lfs to the remote server, and now I want to remove that completely to ensure that it is not occupying my git lfs storage space.
I use both bfg and filter-repo and follow the procedure, but I found that no matter what I tried, the large files remains on the server, and the space is not released. The way that I detected that is from the repo setting: it can not be a template repo as it contains lfs files.

[kbtale]

Stack Overflow: How to release storage quota? Check the answers here, there's a tip about using the GitHub "Virtual Agent" to speed up the support process so you don't have to wait for a human.

Official GitHub Docs Explicitly states: "To remove Git LFS objects from a repository, delete and recreate the repository... If you are unable to delete the repository, please contact support for help."

Basically, your local git work is fine, but you're hitting a wall with GitHub's backend retention policy. You either have to wait for support or start with a fresh repo. This is actually expected behavior on GitHub. Rewriting your history with bfg or filter-repo only removes the pointers from your git history, it doesn't automatically delete the actual large binaries from GitHub's servers. They keep those files in a background storage pool to prevent accidental data loss.

[Louis-26]

If possible, how may I manually delete the files on remote server, so that I can free up the space, or in case I push something private that I don't want to share?

[kbtale]

Hmmm, I wish I had better news, but currently, you can't do this manually yourself.

GitHub doesn't give us a button or command to pick and choose specific files to delete from their server. It's designed this way to keep data safe (so you don't accidentally break your history), but it can be super annoying sometimes

If you're just trying to save space, you'll have to stick to the methods we talked about earlier. Using the "Virtual Agent" via Support is usually the best middle ground if you don't want to delete your whole repo.

Now... If you pushed something private (like a password or key) please be careful! Even if you clean your history locally, the file technically stays on the server for a while. If it's something really sensitive, the safest thing to do is delete the repository completely and start over. It's the only way to be 100% sure it's gone instantly, at least according to the official docs on removing files from Git Large File Storage

[Louis-26]

You mean "stay for a while", how long?
after certain time, they get removed as they are unreferrenced?

[imadev26]

This is a common Git LFS issue — deleting files locally does NOT immediately free storage.

Here’s how to properly remove LFS files and reclaim space 👇

---

❗ Why Storage Isn’t Released Immediately

• Git LFS tracks file history
• Deleted files still exist in Git history
• Storage is freed only after references are removed

---

✅ Correct Way to Remove LFS Files

1. Stop tracking the file

git lfs untrack "large-file.bin"

[HadyMohamedElhadyHassan]

Hi,

The reason the large files are still occupying space is because Git LFS keeps the objects on the server even after removing them locally or rewriting history with BFG / filter-repo. To completely free the storage, you can do the following:

Prune local LFS objects:

git lfs prune

Verify which LFS objects are still tracked:

git lfs ls-files

Remove old LFS objects from history (if needed) using filter-repo:

git filter-repo --strip-blobs-bigger-than 100M

(replace 100M with the appropriate size threshold)

Force push rewritten history to the remote (be careful, this rewrites commits):

git push origin --force --all
git push origin --force --tags

Finally, contact GitHub Support to permanently delete LFS objects from the server, as just rewriting history does not automatically free server storage.

Keep in mind that after the server cleans up the objects, the repo may become eligible to be a template repo again.

Hope this helps and you’re able to free the space!

[Louis-26]

If I run git lfs prune, but I didn't contact github, would I get freed space?

[HadyMohamedElhadyHassan]

Hi, the reason the large files are still occupying space is because Git LFS keeps the objects on the server even after removing them locally or rewriting history with BFG / filter-repo. To completely free the storage, you can do the following: (1) Prune local LFS objects: git lfs prune; (2) Verify which LFS objects are still tracked: git lfs ls-files; (3) Remove old LFS objects from history (if needed) using filter-repo: git filter-repo --strip-blobs-bigger-than 100M (replace 100M with the appropriate size threshold); (4) Force push rewritten history to the remote (be careful, this rewrites commits): git push origin --force --all and git push origin --force --tags; (5) Finally, contact GitHub Support to permanently delete LFS objects from the server, as just rewriting history does not automatically free server storage. Keep in mind that after the server cleans up the objects, the repo may become eligible to be a template repo again. Hope this helps and you’re able to free the space!

[Louis-26]

I learn from other sources that once first 4 steps are done, the files would be automatically removed from the server after 30 days.
I'm using BFG.

[HadyMohamedElhadyHassan]

Thanks for sharing this info! You are absolutely right. Waiting for the automatic garbage collection works if there's no rush. However, contacting GitHub Support (Step 5) is recommended if someone hits the storage quota limit and needs to free up space immediately to resume pushing changes.

Good luck with BFG

[Louis-26]

well, so are you sure about the specific time of automatic garbage collection in github server for lfs?
I'm not quite sure about that.

[HadyMohamedElhadyHassan]

You’re right to be cautious. GitHub doesn’t officially guarantee a specific timeframe for automatic garbage collection of LFS objects. The 30-day estimate comes from community experience and reports, but it can vary. If you need to free space immediately, contacting GitHub Support is the safest option.

[Louis-26]

Thanks. Do you have any previous experience without contacting github? How long does it take?
I don't think contacting them makes sense, as they never reply to my messages.