BUG - Auto Pull Operation of Repositorys with LFS enable dont´t Sync New LFS Content #14116

Closed
opened 2025-11-02 11:03:22 -06:00 by GiteaMirror · 8 comments
Owner

Originally created by @NicholasRush on GitHub (Feb 8, 2025).

Description

Hello everyone,

i currently have two LXC instances running with Gitea. Both in the internal network with a self-signed certificate. Instance 1 is my "work instance" on which I am actively working. Instance 2 (offsite) pulls the repos I am working on from instance 1. This works so far. But now I have started using Git-LFS in some repos. And that is where the problem comes in. When initially pulling a repo, it creates all the LFS data of the repository in the LFS storage of instance 2 in addition to the LFS indexes. However, if data is then added to the repository, it no longer syncs this LFS data, just the repo data itself. The whole thing can be fixed by deleting the corresponding "pull" repos on instance 2 and creating new ones. But that is not the point of the matter. I don't want to work in a single instance either, because the work instance (instance 1) actually only contains projects that are actively being worked on.

Gitea Version

1.23.1

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

git version 2.39.5

Operating System

Debian Linux 12.9

How are you running Gitea?

LXC - Container

Database

MySQL/MariaDB

Originally created by @NicholasRush on GitHub (Feb 8, 2025). ### Description Hello everyone, i currently have two LXC instances running with Gitea. Both in the internal network with a self-signed certificate. Instance 1 is my "work instance" on which I am actively working. Instance 2 (offsite) pulls the repos I am working on from instance 1. This works so far. But now I have started using Git-LFS in some repos. And that is where the problem comes in. When initially pulling a repo, it creates all the LFS data of the repository in the LFS storage of instance 2 in addition to the LFS indexes. However, if data is then added to the repository, it no longer syncs this LFS data, just the repo data itself. The whole thing can be fixed by deleting the corresponding "pull" repos on instance 2 and creating new ones. But that is not the point of the matter. I don't want to work in a single instance either, because the work instance (instance 1) actually only contains projects that are actively being worked on. ### Gitea Version 1.23.1 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version git version 2.39.5 ### Operating System Debian Linux 12.9 ### How are you running Gitea? LXC - Container ### Database MySQL/MariaDB
GiteaMirror added the topic/lfsissue/needs-feedbacktype/bug labels 2025-11-02 11:03:22 -06:00
Author
Owner

@lunny commented on GitHub (Jun 19, 2025):

How were these repositories pulled to the 2nd instances? If you are using mirrors feature, there is a include lfs option, you need to check.

@lunny commented on GitHub (Jun 19, 2025): How were these repositories pulled to the 2nd instances? If you are using mirrors feature, there is a `include lfs` option, you need to check.
Author
Owner

@NicholasRush commented on GitHub (Jun 20, 2025):

How were these repositories pulled to the 2nd instances? If you are using mirrors feature, there is a include lfs option, you need to check.

On every new setup of a mirror i´ll check the include lfs option, but this works only once. If you change files which belong to LFS-Links these files would not synchronized in a existent mirror. Thats the real problem. Its only working once on setup and then not anymore. My two instances are on separate sites, but there is no firewall between them, that could block something. Both instaces are on my internal network.

@NicholasRush commented on GitHub (Jun 20, 2025): > How were these repositories pulled to the 2nd instances? If you are using mirrors feature, there is a `include lfs` option, you need to check. On every new setup of a mirror i´ll check the `include lfs` option, but this works only once. If you change files which belong to LFS-Links these files would not synchronized in a existent mirror. Thats the real problem. Its only working once on setup and then not anymore. My two instances are on separate sites, but there is no firewall between them, that could block something. Both instaces are on my internal network.
Author
Owner

@NicholasRush commented on GitHub (Aug 24, 2025):

I updated both Gitea sites last week to 1.24.5 and the problem remains the same.

@NicholasRush commented on GitHub (Aug 24, 2025): I updated both Gitea sites last week to 1.24.5 and the problem remains the same.
Author
Owner

@lunny commented on GitHub (Sep 30, 2025):

Could you reproduce it in https://demo.gitea.com? I couldn't reproduce it in my dev env.

@lunny commented on GitHub (Sep 30, 2025): Could you reproduce it in https://demo.gitea.com? I couldn't reproduce it in my dev env.
Author
Owner

@NicholasRush commented on GitHub (Sep 30, 2025):

@lunny Hello, you can easily check this: create a repository with specific LFS filters. And upload only one file there, which will be synchronized to LFS. Then mirror (pull) the repository, including the LFS data, from another Gitea instance. The first time, it will also transfer the LFS data. If you now add another test file to the first instance and start the resync in the mirrored repository on the other instance, only the LFS pointer of the new file will be transferred, but not the referenced file itself. This means that the file will not be loaded into the LFS storage of the other instance. Unfortunately, this cannot be reproduced with the online demo.

@NicholasRush commented on GitHub (Sep 30, 2025): @lunny Hello, you can easily check this: create a repository with specific LFS filters. And upload only one file there, which will be synchronized to LFS. Then mirror (pull) the repository, including the LFS data, from another Gitea instance. The first time, it will also transfer the LFS data. If you now add another test file to the first instance and start the resync in the mirrored repository on the other instance, only the LFS pointer of the new file will be transferred, but not the referenced file itself. This means that the file will not be loaded into the LFS storage of the other instance. Unfortunately, this cannot be reproduced with the online demo.
Author
Owner

@lunny commented on GitHub (Oct 1, 2025):

That's the steps I did in my dev environment and I cannot reproduce it. I created a mirror repository in https://demo.gitea.com/lunny/lfs-test-2/src/branch/master/FiraCode-Regular.woff which is a mirror of https://gitea.com/lunny/lfs-test-2

@lunny commented on GitHub (Oct 1, 2025): That's the steps I did in my dev environment and I cannot reproduce it. I created a mirror repository in https://demo.gitea.com/lunny/lfs-test-2/src/branch/master/FiraCode-Regular.woff which is a mirror of https://gitea.com/lunny/lfs-test-2
Author
Owner

@NicholasRush commented on GitHub (Oct 1, 2025):

@lunny Hi, this is confusing me. My Gitea instances only run on the internal network. Synchronization only works once, and it includes the LFS component. If you synchronize again, nothing happens because only the LFS pointer files are transferred. However, I don't know the configuration for your public instance either. I have the following additional configuration in both instances:

[migrations]
ALLOWED_DOMAINS = 
ALLOW_LOCALNETWORKS = true
SKIP_TLS_VERIFY = true
BLOCKED_DOMAINS = ```
@NicholasRush commented on GitHub (Oct 1, 2025): @lunny Hi, this is confusing me. My Gitea instances only run on the internal network. Synchronization only works once, and it includes the LFS component. If you synchronize again, nothing happens because only the LFS pointer files are transferred. However, I don't know the configuration for your public instance either. I have the following additional configuration in both instances: ``` [migrations] ALLOWED_DOMAINS = ALLOW_LOCALNETWORKS = true SKIP_TLS_VERIFY = true BLOCKED_DOMAINS = ```
Author
Owner

@GiteaBot commented on GitHub (Oct 31, 2025):

We close issues that need feedback from the author if there were no new comments for a month. 🍵

@GiteaBot commented on GitHub (Oct 31, 2025): We close issues that need feedback from the author if there were no new comments for a month. :tea:
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#14116