Keep LFS objects in the repository #4088

New Issue

GiteaMirror · 2025-11-02T05:37:14-06:00

GiteaMirror commented

2025-11-02 05:37:14 -06:00

Originally created by @tinywrkb on GitHub (Oct 9, 2019).

Gitea keeps LFS objects separately from the repository.
A repository is kept at GITEAHOME/repos/USER/REPO.git
All LFS objects kept at GITEAHOME/data/lfs

I suggest for Gitea to keep LFS objects inside the bare repository the same way it is kept when cloning a repo with LFS objects locally in order push to a mirror. e.g.

git clone --bare <SOURCE-URL>
git lfs fetch origin --all
git push --mirror <TARGET-URL>
git lfs push --all <TARGET-URL>

The LFS objects are then kept in REPO.git/.git/lfs/objects
This way if Gitea is down it's still possible for the user to clone the repo and checkout the LFS data. e.g.

git clone --no-checkout source_path local_repo
cd local_repo
mkdir -p .git/lfs
cp -r source_path/.git/lfs/objects .git/lfs/objects
git checkout HEAD
git lfs prune

Originally created by @tinywrkb on GitHub (Oct 9, 2019). Gitea keeps LFS objects separately from the repository. A repository is kept at `GITEAHOME/repos/USER/REPO.git` All LFS objects kept at `GITEAHOME/data/lfs` I suggest for Gitea to keep LFS objects inside the bare repository the same way it is kept when cloning a repo with LFS objects locally in order push to a mirror. e.g. ``` git clone --bare <SOURCE-URL> git lfs fetch origin --all git push --mirror <TARGET-URL> git lfs push --all <TARGET-URL> ``` The LFS objects are then kept in `REPO.git/.git/lfs/objects` This way if Gitea is down it's still possible for the user to clone the repo and checkout the LFS data. e.g. ``` git clone --no-checkout source_path local_repo cd local_repo mkdir -p .git/lfs cp -r source_path/.git/lfs/objects .git/lfs/objects git checkout HEAD git lfs prune ```

GiteaMirror closed this issue

2025-11-02 05:37:14 -06:00

GiteaMirror commented

2025-11-02 05:37:15 -06:00

@zeripath commented on GitHub (Oct 9, 2019):

How are you cloning or doing anything to Gitea's repositories without Gitea being up?

You shouldn't be using Gitea's repositories without going through Gitea.

@zeripath commented on GitHub (Oct 9, 2019): How are you cloning or doing anything to Gitea's repositories without Gitea being up? You shouldn't be using Gitea's repositories without going through Gitea.

GiteaMirror commented

2025-11-02 05:37:16 -06:00

@tinywrkb commented on GitHub (Oct 9, 2019):

I usually don't but the idea is that in the case of emergency, when Gitea is down for any type of reason, the user could still check out a local copy.
We can do this now for non-LFS repositories as the they are kept as bare repos, why not to have this possible also for LFS? so the user can always get his data even when Gitea is down.

@tinywrkb commented on GitHub (Oct 9, 2019): I usually don't but the idea is that in the case of emergency, when Gitea is down for any type of reason, the user could still check out a local copy. We can do this now for non-LFS repositories as the they are kept as bare repos, why not to have this possible also for LFS? so the user can always get his data even when Gitea is down.

GiteaMirror commented

2025-11-02 05:37:16 -06:00

@zeripath commented on GitHub (Oct 10, 2019):

The LFS files are shared across forks of the same repository (and across all repos.) The idea is that these files are large and so there should be only one copy on the server at any time.

If you want to get to the LFS files outside of Gitea they're just stored as filename sharded sha256 slightly differently sharded from the way the local sharding occurs - but in the same way gitlab shards for compatibility. In the case that Gitea is permanently down you're welcome to reshard the lfs as you see fit.

I don't think we should be really suggesting or making it easy for people to be pushing or pulling from Gitea's repos except through Gitea. If you do that there is a potential to break Gitea in a huge number of ways.

@zeripath commented on GitHub (Oct 10, 2019): The LFS files are shared across forks of the same repository (and across all repos.) The idea is that these files are large and so there should be only one copy on the server at any time. If you want to get to the LFS files outside of Gitea they're just stored as filename sharded sha256 slightly differently sharded from the way the local sharding occurs - but in the same way gitlab shards for compatibility. In the case that Gitea is permanently down you're welcome to reshard the lfs as you see fit. I don't think we should be really suggesting or making it easy for people to be pushing or pulling from Gitea's repos except through Gitea. If you do that there is a potential to break Gitea in a huge number of ways.

GiteaMirror commented

2025-11-02 05:37:16 -06:00

@tinywrkb commented on GitHub (Oct 10, 2019):

Bypassing Gitea and pushing directly to a repo wasn't on my mind.

Anyway, thank you for the prompt and detailed reply.

@tinywrkb commented on GitHub (Oct 10, 2019): Bypassing Gitea and pushing directly to a repo wasn't on my mind. Anyway, thank you for the prompt and detailed reply.

GiteaMirror referenced this issue

2025-11-02 12:30:33 -06:00

[PR #4096] [MERGED] Add make command to validate swagger file #17239

GiteaMirror referenced this issue

2025-11-02 12:31:47 -06:00

[PR #4220] [MERGED] Fix swagger errors #17289

Sign in to join this conversation.