Understanding storage concepts of Git LFS with NXRM 3.13.3 OSS


I created Git LFS hosted repository to integrate with my GitHub source repositories. I noticed in NX that the storage names of the LFS files have some type of internal database string. When I deleted the LFS files from GitHub, I expected to see the NX gitlfs repo clear of those files. Is there a clean step I can execute to remove those files?


|Format| gitlfs|

|Component Name ad7facb2586fc6e966c004d7d1d16b024f5805ff7cb47c7a85dabd8b48892ca7|


|Content type|application/octet-stream|

|File size|4 KB|

|Blob created|Sun Sep 16 2018 15:03:10 GMT-0400 (Eastern Daylight Time)|
|Blob updated|Sun Sep 16 2018 15:03:10 GMT-0400 (Eastern Daylight Time)|

|Last 30 days|1 downloads|
|Last downloaded|Sun Sep 16 2018|
|Locally cached|true|
|Blob reference|storeloc@6E2D7CAF-B224B69C-D1BD403F-B855531E-EDD424EF:0aa0e9d0-f975-4547-91e2-6c56a025657e|

|Containing repo|server-lfs-hosted|

|Uploader’s IP Address||


Given the constraints of Git-LFS, its content is completely opaque from a Nexus Repository perspective. There’s no rule that Nexus Repository can apply to determine whether the file is used/unused/obsolete since the links are on the Git side. So, deletion of content from the Git-LFS side will not automatically delete the content on the Nexus Repository side.

This is actually a limitation within Git and Git-LFS itself. In this help article, GitHub notes:

“After you remove files from Git LFS, the Git LFS objects still exist on the remote storage and will continue to count toward your Git LFS storage quota.”

If you wish to delete content within Nexus Repository, we do advise proceeding with caution per our note in the documentation:

“Removing content from a Git LFS repository is not recommended and no cleanup task exists. Removing files from Git LFS means that those files will no longer be available from your associated Git repository, and the pointer files in Git will point to content that no longer exists. A one-to-one mapping between Git LFS repositories and Git repositories and the use of dedicated blobstores may mitigate some concerns by making it easier to add additional storage in the future.”


Thanks. I thought this was the case. Just needed confirmation.