# Will LFS related functionality come to hf\_api?

**URL:** <https://discuss.huggingface.co/t/will-lfs-related-functionality-come-to-hf-api/146721>\
**Category:** 🤗Hub\
**Created:** [March 21, 2025, 1:35am UTC](https://discuss.huggingface.co/t/will-lfs-related-functionality-come-to-hf-api/146721 "2025-03-21T01:35:31Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![Wauplin](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/wauplin/32/40815_2.png) [@Wauplin](https://discuss.huggingface.co/u/Wauplin)\
**Post date:** [March 24, 2025, 9:38am UTC](https://discuss.huggingface.co/t/will-lfs-related-functionality-come-to-hf-api/146721/8 "2025-03-24T09:38:08Z")

</div>

Right, I haven’t spot this issue indeed. I’ll ask around internally what can be done in this case. Note that repositories on the Hub are meant to version data and keep the history. And `super_squash_commit` meant to be a power-user method to reduce the number of commits but not thought it term of “deleting previously uploaded data”. If you do not need versioning (i.e. if you do not need past checkpoints to be stored) I can advice to store checkpoints in a temporary repository and then delete it once the “final checkpoints” are ready. Instead of the

```py
api.delete_files(repo_id=repo_id, revision=branch, delete_patterns='*')
api.super_squash_history(repo_id=repo_id, branch=branch)
api.delete_branch(repo_id=repo_id, branch=branch)

```

you could even do something like

```py
api.delete_repo(repo_id=repo_id)
api.create_repo(repo_id=repo_id)
api.upload_file(...)

```

Of course this would come with some drawbacks (total history is lost, community tab is lost, link to collections is lost etc.) but depending on your use case and workflow it can be a good workaround.

---

_[View the full topic](https://discuss.huggingface.co/t/will-lfs-related-functionality-come-to-hf-api/146721)._