I didn't see this mentioned anywhere else in Issues (or the Google), but it seems that the Gitlab archiver doesn't honor Git-LFS references in a repository when it's streaming an archive to a user. I encountered this in the sameersbn/gitlab:8.5.4 container. To reproduce, create a Git repository with Git-LFS enabled, commit a Git-LFS-tracked file and push it to GitLab. Then click Download Zip. The created archive will have the Git-LFS reference instead of the actual file. Assuming a user's intended result of clicking "Download Zip" is to receive a zip file with a Git-metadata-free snapshot of the repository as of a particular branch/commit, this seems like a bug. Particularly because the data needed for Git-LFS to resolve those files isn't included in the archive... UPDATE: 2020-10-13 This is the data flow for handling this issue: ```mermaid sequenceDiagram Client->>+Workhorse: GET /group/project/-/archive/master.zip Workhorse->>+Rails: GET /group/project/-/archive/master.zip Rails->>+Workhorse: Gitlab-Workhorse-Send-Data git-archive Workhorse->>Gitaly: SendArchiveRequest Gitaly->>Git: git archive master Git->>Smudge: OID 12345 Smudge->>+Workhorse: GET /internal/api/v4/lfs?oid=12345&gl_repository=project-1234 Workhorse->>+Rails: GET /internal/api/v4/lfs?oid=12345&gl_repository=project-1234 Rails->>+Workhorse: Gitlab-Workhorse-Send-Data send-url Workhorse->>Smudge: <LFS data> Smudge->>Git: <LFS data> Git->>Gitaly: <streamed data> Gitaly->>Workhorse: <streamed data> Workhorse->>Client: master.zip ```