LFS files display as plaintext #12622

New Issue

GiteaMirror · 2025-11-02T10:16:18-06:00

GiteaMirror commented

2025-11-02 10:16:18 -06:00

Originally created by @Bottersnike on GitHub (Mar 9, 2024).

Description

After updating gitea to 1.21.7, LFS files are now displaying in the web interface as their plaintext content, rather than a download link. Cloning the repository populates the files with their LFS content as expected.

Screenshots

Gitea Version

1.21.7

I have attempted a downgrade to 1.26.1+1 (from apt) and this issue also occurred. Older versions are not present in the repositories and this is a production server so switching off the repositories is not an option.

Can you reproduce the bug on the Gitea demo site?

I was unable to reproduce on the demo site due to an inability to upload LFS objects.

Browser Version

Microsoft Edge 122.0.2365.66

Originally created by @Bottersnike on GitHub (Mar 9, 2024). ### Description After updating gitea to 1.21.7, LFS files are now displaying in the web interface as their plaintext content, rather than a download link. Cloning the repository populates the files with their LFS content as expected. ### Screenshots ![msedge_ARmvgzpnKa](https://github.com/go-gitea/gitea/assets/7524553/79131857-998d-48cc-b955-6adeb93485a1) ### Gitea Version 1.21.7 I have attempted a downgrade to 1.26.1+1 (from apt) and this issue also occurred. Older versions are not present in the repositories and this is a production server so switching off the repositories is not an option. ### Can you reproduce the bug on the Gitea demo site? I was unable to reproduce on the demo site due to an inability to upload LFS objects. ### Browser Version Microsoft Edge 122.0.2365.66

GiteaMirror added the issue/needs-feedback type/bug labels 2025-11-02 10:16:18 -06:00

GiteaMirror closed this issue

2025-11-02 10:16:18 -06:00

GiteaMirror commented

2025-11-02 10:16:19 -06:00

@Bottersnike commented on GitHub (Mar 9, 2024):

As an interesting observation, it appears files that were pushed prior to the update display on the web interface file (see attached photo). I'm unsure what could have caused this change as cloning works for both files.

@Bottersnike commented on GitHub (Mar 9, 2024): As an interesting observation, it appears files that were pushed prior to the update display on the web interface file (see attached photo). I'm unsure what could have caused this change as cloning works for both files. ![image](https://github.com/go-gitea/gitea/assets/7524553/f3739cfe-ac50-4f5e-8c70-02e10da2d2b4)

GiteaMirror commented

2025-11-02 10:16:19 -06:00

@Bottersnike commented on GitHub (Mar 10, 2024):

Having had a look at the repository history, the file causing the problem raised in this issue was originally present as a non-LFS file, and was then replaced with an LFS file when its size became unmanageable. The second file mentioned was never uploaded non-LFS, and has always been LFS. This behaviour with regards to how the web interface is displaying the LFS files appears to be consistent.

My hypothesis from this (however I have not yet had the opportunity to do testing) is the web interface is using the original state of the file to decide if it is LFS or not rather than the current file state.

@Bottersnike commented on GitHub (Mar 10, 2024): Having had a look at the repository history, the file causing the problem raised in this issue was originally present as a non-LFS file, and was then replaced with an LFS file when its size became unmanageable. The second file mentioned was never uploaded non-LFS, and has always been LFS. This behaviour with regards to how the web interface is displaying the LFS files appears to be consistent. My hypothesis from this (however I have not yet had the opportunity to do testing) is the web interface is using the original state of the file to decide if it is LFS or not rather than the current file state.

GiteaMirror commented

2025-11-02 10:16:19 -06:00

@Bottersnike commented on GitHub (Mar 10, 2024):

After discussion with the repository owner, they pushed a commit that removed the problematic file, followed by a second commit that re-added the file as LFS. As expected this has caused it to begin displaying correctly in the web interface, so I believe this further suggests the issue is related to files that were switched to LFS at a later time.

@Bottersnike commented on GitHub (Mar 10, 2024): After discussion with the repository owner, they pushed a commit that removed the problematic file, followed by a second commit that re-added the file as LFS. As expected this has caused it to begin displaying correctly in the web interface, so I believe this further suggests the issue is related to files that were switched to LFS at a later time.

GiteaMirror commented

2025-11-02 10:16:20 -06:00

@Zettat123 commented on GitHub (Mar 11, 2024):

Hi @Bottersnike . I think this is not a ui bug but a backend bug. But I cannot reproduce it. Could you do some tests on your instance and provide us with some detailed steps to help us reproduce this bug?

@Zettat123 commented on GitHub (Mar 11, 2024): Hi @Bottersnike . I think this is not a ui bug but a backend bug. But I cannot reproduce it. Could you do some tests on your instance and provide us with some detailed steps to help us reproduce this bug?

GiteaMirror commented

2025-11-02 10:16:20 -06:00

@Bottersnike commented on GitHub (Mar 11, 2024):

Testing the initial theory I was likewise unable to reproduce, so I suspect something additional may be at play here. 287aa42b32/SDGT/150.zip is the commit that caused this (linked to the specific file shown in OP).

git show on that commit (first image) doesn't show anything interesting as best I can tell though it does appear suspect to me that compared to the commit that re-added the files after deleting them (second image) git doesn't want to show their LFS pointer content

When that branch was checked out the LFS files were perpetually being shown by git as modified, and I wasn't able to even do a reset --hard or stash to clean my working tree in order to switch back to head. I had to checkout -f master. When on the latest commit git status reports the working tree to be clean as expected.

Something very weird has gone on here, but I'm unfortunately not familiar enough with the git internals to know what or where to start looking.

@Bottersnike commented on GitHub (Mar 11, 2024): Testing the initial theory I was likewise unable to reproduce, so I suspect something additional may be at play here. https://gitea.tendokyu.moe/Dniel97/SEGAguide/src/commit/287aa42b3260ede6641fe021d202c65db7a0ca62/SDGT/150.zip is the commit that caused this (linked to the specific file shown in OP). `git show` on that commit (first image) doesn't show anything interesting as best I can tell though it does appear suspect to me that compared to the commit that re-added the files after deleting them (second image) git doesn't want to show their LFS pointer content ![image](https://github.com/go-gitea/gitea/assets/7524553/4fe94b77-4d5f-4ee9-9a1e-c3b4e41f86bf) ![image](https://github.com/go-gitea/gitea/assets/7524553/e0097431-7196-42fb-9730-69365292e099) When that branch was checked out the LFS files were perpetually being shown by git as modified, and I wasn't able to even do a `reset --hard` or `stash` to clean my working tree in order to switch back to head. I had to `checkout -f master`. When on the latest commit `git status` reports the working tree to be clean as expected. ![image](https://github.com/go-gitea/gitea/assets/7524553/bce29e97-2305-48cf-9bf4-6125e7f37b97) Something very weird has gone on here, but I'm unfortunately not familiar enough with the git internals to know what or where to start looking.

GiteaMirror commented

2025-11-02 10:16:20 -06:00

@Zettat123 commented on GitHub (Mar 13, 2024):

Thank you for the link. I noticed the files that were uploaded before enabling LFS displayed as plain text after 287aa42b. Do you know what the author did in this commit?

@Zettat123 commented on GitHub (Mar 13, 2024): Thank you for the link. I noticed the files that were uploaded before enabling LFS displayed as plain text after [`287aa42b`](https://gitea.tendokyu.moe/Dniel97/SEGAguide/commit/287aa42b3260ede6641fe021d202c65db7a0ca62). Do you know what the author did in this commit?

GiteaMirror commented

2025-11-02 10:16:20 -06:00

@Bottersnike commented on GitHub (Mar 13, 2024):

In discussion with them it appears they ran git lfs track "*.zip" in 24af5eb61f then used git add in the subsequent commits.

So I think I did

git lfs track *.zip
git add .gitattributes
git commit -m "LFS enabled"
git push origin master

git add SDDT/139.zip
git commit -m "SDDT 1.39 updated"
git push origin master

git add SDDT/140.zip
git commit -m "SDDT 1.40 added"

git add * (all files i wanted)
git commit -m "Updated using LFS"
git push origin master

The author is on windows so unfortunately no shell history to know for sure.

@Bottersnike commented on GitHub (Mar 13, 2024): In discussion with them it appears they ran `git lfs track "*.zip"` in [24af5eb61f](https://gitea.tendokyu.moe/Dniel97/SEGAguide/commit/24af5eb61f239666683038c4bf0167de6991db3d) then used `git add` in the subsequent commits. > So I think I did > > `git lfs track *.zip` > `git add .gitattributes` > `git commit -m "LFS enabled"` > `git push origin master` > > `git add SDDT/139.zip` > `git commit -m "SDDT 1.39 updated"` > `git push origin master` > > `git add SDDT/140.zip` > `git commit -m "SDDT 1.40 added"` > > `git add * (all files i wanted)` > `git commit -m "Updated using LFS"` > `git push origin master` The author is on windows so unfortunately no shell history to know for sure.

GiteaMirror commented

2025-11-02 10:16:20 -06:00

@GiteaBot commented on GitHub (Apr 12, 2024):

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

@GiteaBot commented on GitHub (Apr 12, 2024): We close issues that need feedback from the author if there were no new comments for a month. :tea:

GiteaMirror commented

2025-11-02 10:16:21 -06:00

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

It works for me when I migrating your repository to my local machine which is main branch(1.25-dev)

@lunny commented on GitHub (Jun 19, 2025): It works for me when I migrating your repository to my local machine which is main branch(1.25-dev) ![Image](https://github.com/user-attachments/assets/8b36fe31-b94e-4e3c-8d17-fff0a3b661a1)

GiteaMirror commented

2025-11-02 10:16:21 -06:00

@GiteaBot commented on GitHub (Sep 24, 2025):

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

@GiteaBot commented on GitHub (Sep 24, 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.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#12622