gitea: Archive/Download do not include LFS files or Submodules

Gitea version (or commit ref): 1.5.0
Git version: 2.16.4
Operating system: centos 7
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist: Downloads of LFS files

Description

With git-lfs installed and enabled on both the gitea server host and the client host, LFS controlled files do not get added properly to the .zip or .tar.gz files when:

Using the Download Repository button
Downloading a release

Instead of the expected file in the .zip or .tar.gz, a text file of the same name is placed in the file.

The rest endpoint also functions in the same way.

GET /repos/{owner}/{repo}/raw/{filepath}

In other respects, git-lfs works as expected when using git command line to interact with the repo.

Screenshots

Text files look like this:

version https://git-lfs.github.com/spec/v1
oid sha256:a7da80fc96bc0dd73ea0416fda5dfe1321910517634d4b142903a9fbab24f196
size 1465634

About this issue

Original URL
State: open
Created 6 years ago
Reactions: 21
Comments: 21 (8 by maintainers)

Most upvoted comments

Still an issue in v1.19.0

garyritchie on Sep 5, 2023

There is a wrapper around git archive that would allows to at least handles submodules. https://github.com/fabacab/git-archive-all.sh/blob/master/git-archive-all.sh

Maybe gitea could use it ?

simchanu29 on Nov 27, 2020

Just wanted to add my two cents to this conversation. Without this feature there is not much point in using git lfs at all. All the development work happens using lfs and when a production version is produced, it contains lots of nasty surprises in blank pointer files. My current approach is to not use lfs at all and handle big binaries separately to git. This creates a lot of extra mess that would be much easier if I could just download the archive.

RogueRaider on Jun 22, 2020

I suspect they rewrote the command. Back in November 2018 https://github.com/git-lfs/git-lfs/issues/1322#issuecomment-426822783 states that they didn’t include lfs files (and likely submodules) in their zips.

I think that’s what we’re going to have to do unfortunately.

zeripath on Jun 23, 2019

Still an issue in v1.20.3 🥲

Laurent2916 on Sep 5, 2023

This again leads to the slightly annoying issue whereby we don’t know what files are LFS files except by reading them and checking if they’re a pointer or not.

Similarly we need to do this zipping in the context of the current user and repository. In the case of submodules - it’s conceivable that the zip that one user downloads may not be the same as the zip another user gets - I guess that’s ok but it means caching these might be difficult unless we cache them with the associated permission state.

Finally we must be very careful indeed about which submodules we’re happy to include, if any - perhaps just allow those that are local to the gitea instance?

zeripath on Jun 23, 2019