Git LFS image linking not possible #2762

New Issue

GiteaMirror · 2025-11-02T04:47:18-06:00

GiteaMirror commented

2025-11-02 04:47:18 -06:00

Originally created by @diondokter on GitHub (Jan 16, 2019).

Gitea version (or commit ref): 1.7 (Downloaded from https://dl.gitea.io/gitea/1.7/) (8006b1b in footer of the instance)
Git version: 2.17.1
Operating system: Ubuntu 18.04
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: -

Description

When linking to an image that is stored in LFS, you get the LFS text. For example:
https://mywebsite.com/diondokter/myrepo/raw/branch/develop/Design/Images/myimage.jpg gives

version https://git-lfs.github.com/spec/v1
oid sha256:e31e396000df86f9a888eea93efec5ad46fa68c1d3f8d6aa8f42991e137deaad
size 14365

When linking to the image in markdown, it will not appear which is quite inconvenient.
Can this be resolved?

I can't repro this issue on try.gitea.io because (I suspect) LFS is turned off.

Originally created by @diondokter on GitHub (Jan 16, 2019). - Gitea version (or commit ref): 1.7 (Downloaded from https://dl.gitea.io/gitea/1.7/) (8006b1b in footer of the instance) - Git version: 2.17.1 - Operating system: Ubuntu 18.04 - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - [ ] Not relevant - Log gist: - ## Description When linking to an image that is stored in LFS, you get the LFS text. For example: https://mywebsite.com/diondokter/myrepo/raw/branch/develop/Design/Images/myimage.jpg gives > version https://git-lfs.github.com/spec/v1 > oid sha256:e31e396000df86f9a888eea93efec5ad46fa68c1d3f8d6aa8f42991e137deaad > size 14365 When linking to the image in markdown, it will not appear which is quite inconvenient. Can this be resolved? I can't repro this issue on try.gitea.io because (I suspect) LFS is turned off. > ![image](https://user-images.githubusercontent.com/8545127/51275289-cb3ad300-19d1-11e9-8b01-7bf9e1c1cbac.png)

GiteaMirror added the type/feature label 2025-11-02 04:47:18 -06:00

GiteaMirror closed this issue

2025-11-02 04:47:19 -06:00

GiteaMirror commented

2025-11-02 04:47:20 -06:00

@zeripath commented on GitHub (Jan 20, 2019):

The problem is that we may need the raw route to still actually give the raw file pre-smudge... I hate to say it but what does github do?

@zeripath commented on GitHub (Jan 20, 2019): The problem is that we may need the raw route to still actually give the raw file pre-smudge... I hate to say it but what does github do?

GiteaMirror commented

2025-11-02 04:47:20 -06:00

@diondokter commented on GitHub (Jan 20, 2019):

I made a quick repo on github. That seems to work fine.
It's public and you can view it here: https://github.com/diondokter/LFS-Test

The first image is in LFS, the second one is not.

Also note that when you go to the LFS image file, it doesn't ask you if you want to see the raw file and actually displays the image. (https://github.com/diondokter/LFS-Test/blob/master/TestImage.jpg)

@diondokter commented on GitHub (Jan 20, 2019): I made a quick repo on github. That seems to work fine. It's public and you can view it here: https://github.com/diondokter/LFS-Test The first image is in LFS, the second one is not. Also note that when you go to the LFS image file, it doesn't ask you if you want to see the raw file and actually displays the image. (https://github.com/diondokter/LFS-Test/blob/master/TestImage.jpg)

GiteaMirror commented

2025-11-02 04:47:20 -06:00

@zeripath commented on GitHub (Jan 20, 2019):

OK, so github's raw does provide the pointer. https://raw.githubusercontent.com/diondokter/LFS-Test/master/TestImage.jpg

So we probably shouldn't change the results of the raw url. Could you tell me how you linked the image - I'm not quite sure how our wiki works.

@zeripath commented on GitHub (Jan 20, 2019): OK, so github's raw does provide the pointer. https://raw.githubusercontent.com/diondokter/LFS-Test/master/TestImage.jpg So we probably shouldn't change the results of the raw url. Could you tell me how you linked the image - I'm not quite sure how our wiki works.

GiteaMirror commented

2025-11-02 04:47:21 -06:00

@diondokter commented on GitHub (Jan 20, 2019):

If you go to the raw readme file, you can see how it's linked. It's the same in Gitea as it's standard markdown. https://raw.githubusercontent.com/diondokter/LFS-Test/master/README.md

When going to the image itself in the browser, it seems the lfs image and the normal image use different subdomains.
LFS uses 'media.' https://media.githubusercontent.com/media/diondokter/LFS-Test/master/TestImage.jpg
Normal uses 'raw.' https://raw.githubusercontent.com/diondokter/LFS-Test/master/TestImage.gif

I guess that the markdown renderer realizes that the image was an lfs image and links to a different path. In the meanwhile, lfs images are also hosted on the server as actual images.

@diondokter commented on GitHub (Jan 20, 2019): If you go to the raw readme file, you can see how it's linked. It's the same in Gitea as it's standard markdown. https://raw.githubusercontent.com/diondokter/LFS-Test/master/README.md When going to the image itself in the browser, it seems the lfs image and the normal image use different subdomains. LFS uses 'media.' https://media.githubusercontent.com/media/diondokter/LFS-Test/master/TestImage.jpg Normal uses 'raw.' https://raw.githubusercontent.com/diondokter/LFS-Test/master/TestImage.gif I guess that the markdown renderer realizes that the image was an lfs image and links to a different path. In the meanwhile, lfs images are also hosted on the server as actual images.

GiteaMirror commented

2025-11-02 04:47:21 -06:00

@zeripath commented on GitHub (Jan 20, 2019):

So we just link using ![alt]( and ) and the markdown render recognises images and places <img> as appropriate?

@zeripath commented on GitHub (Jan 20, 2019): So we just link using `![alt](` and `)` and the markdown render recognises images and places `<img>` as appropriate?

GiteaMirror commented

2025-11-02 04:47:21 -06:00

@diondokter commented on GitHub (Jan 20, 2019):

A normal link is:
'[link text](link url)'.
To show an image you do it like a link, but with an exclamation mark.
'![link text for when the image can't load](link to image)'

Here's a markdown cheatsheet: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet

@diondokter commented on GitHub (Jan 20, 2019): A normal link is: '[*link text*](*link url*)'. To show an image you do it like a link, but with an exclamation mark. '![*link text for when the image can't load*](*link to image*)' Here's a markdown cheatsheet: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet

GiteaMirror commented

2025-11-02 04:47:22 -06:00

@zeripath commented on GitHub (Jan 20, 2019):

OK

https://github.com/go-gitea/gitea/blob/master/modules/markup/markdown/markdown.go#L109 probably needs to have raw replaced with media
https://github.com/go-gitea/gitea/blob/master/routers/routes/routes.go#L679 needs a new route /media/*
https://github.com/go-gitea/gitea/blob/master/routers/routes/routes.go#L708 probably also needs a new similar route /media
https://github.com/go-gitea/gitea/blob/master/routers/routes/routes.go#L708 needs a new func which deals with Media
https://github.com/go-gitea/gitea/blob/master/routers/repo/download.go#L59 needs a similar func

Now most of the work to do the lfs download is already in the editor somewhere because I know we detect if a file is LFS and ask if you want to download the LFS version.

@zeripath commented on GitHub (Jan 20, 2019): OK * https://github.com/go-gitea/gitea/blob/master/modules/markup/markdown/markdown.go#L109 probably needs to have `raw` replaced with `media` * https://github.com/go-gitea/gitea/blob/master/routers/routes/routes.go#L679 needs a new route `/media/*` * https://github.com/go-gitea/gitea/blob/master/routers/routes/routes.go#L708 probably also needs a new similar route `/media` * https://github.com/go-gitea/gitea/blob/master/routers/routes/routes.go#L708 needs a new func which deals with `Media` * https://github.com/go-gitea/gitea/blob/master/routers/repo/download.go#L59 needs a similar func Now most of the work to do the lfs download is already in the editor somewhere because I know we detect if a file is LFS and ask if you want to download the LFS version.

GiteaMirror commented

2025-11-02 04:47:22 -06:00

@zeripath commented on GitHub (Jan 20, 2019):

https://github.com/go-gitea/gitea/blob/master/routers/repo/view.go#L185 is the place where the editor view detects if an item is an LFS item or not

@zeripath commented on GitHub (Jan 20, 2019): * https://github.com/go-gitea/gitea/blob/master/routers/repo/view.go#L185 is the place where the editor view detects if an item is an LFS item or not

GiteaMirror commented

2025-11-02 04:47:22 -06:00

@zeripath commented on GitHub (Jan 20, 2019):

OK, if you can could you try building from #5787 and test if that solves your problem?

@zeripath commented on GitHub (Jan 20, 2019): OK, if you can could you try building from #5787 and test if that solves your problem?

GiteaMirror commented

2025-11-02 04:47:23 -06:00

@diondokter commented on GitHub (Jan 20, 2019):

I've built gitea following the instructions here on github and on the website. (My first time for gitea)
This PR page appears to render the same on this commit as the page I put up on github.

Screenshot of the gitea page:

The functionality seems to be working. Well done!

@diondokter commented on GitHub (Jan 20, 2019): I've built gitea following the instructions here on github and on the website. (My first time for gitea) This PR page appears to render the same on this commit as the page I put up on github. Screenshot of the gitea page: ![image](https://user-images.githubusercontent.com/8545127/51445686-68667600-1d08-11e9-808f-1ab209b92864.png) The functionality seems to be working. Well done!

GiteaMirror commented

2025-11-02 04:47:23 -06:00

@zeripath commented on GitHub (Jan 21, 2019):

Ah I've just noticed something very disturbing... If you try to commit an LFS pointer file just as a random file https://github.com/go-gitea/gitea/blob/master/routers/repo/view.go#L185 will mean that it gets assigned as an LFS file.

@zeripath commented on GitHub (Jan 21, 2019): Ah I've just noticed something very disturbing... If you try to commit an LFS pointer file just as a random file https://github.com/go-gitea/gitea/blob/master/routers/repo/view.go#L185 will mean that it gets assigned as an LFS file.

GiteaMirror commented

2025-11-02 04:47:24 -06:00

@zeripath commented on GitHub (Jan 21, 2019):

The correct thing is to query the git attributes then the file

@zeripath commented on GitHub (Jan 21, 2019): The correct thing is to query the git attributes then the file

GiteaMirror commented

2025-11-02 04:47:24 -06:00

@diondokter commented on GitHub (Jan 21, 2019):

Does it though?
Consider this scenario: I add .png to the lfs attributes and a png to lfs.
Later I remove the .png file from the attributes. The png will still be in lfs, right?
If I'm correct, you should check the file pointer itself.

@diondokter commented on GitHub (Jan 21, 2019): Does it though? Consider this scenario: I add .png to the lfs attributes and a png to lfs. Later I remove the .png file from the attributes. The png will still be in lfs, right? If I'm correct, you should check the file pointer itself.

GiteaMirror commented

2025-11-02 04:47:25 -06:00

@zeripath commented on GitHub (Jan 21, 2019):

OK, you have two repositories A and B, A has lfs set up and you commit a file F.jpg which gets pointered to P.jpg. B doesn't have lfs set up, and you manage to get a copy of the pointer file P.jpg and commit that.

On gitea this file P.jpg when browsing B will be said to be a Git LFS file - even though it isn't and my patchset will display P.jpg as a jpeg although when you clone B you won't get any filtering as B doesn't have git-lfs set up.

Similarly, there's a weirdness in github's interface - if you delete the .jpg from the .gitattributes then technically those files stop being lfs - however, github will continue to show them as if they're LFS - they must be storing the filename with the lfs status - which I guess is safe than relying on parsing gitattributes as there may be filters other than lfs that actually end up with adding stuff to the lfs.

@zeripath commented on GitHub (Jan 21, 2019): OK, you have two repositories A and B, A has lfs set up and you commit a file F.jpg which gets pointered to P.jpg. B doesn't have lfs set up, and you manage to get a copy of the pointer file P.jpg and commit that. On gitea this file P.jpg when browsing B will be said to be a Git LFS file - even though it isn't and my patchset will display P.jpg as a jpeg although when you clone B you won't get any filtering as B doesn't have git-lfs set up. Similarly, there's a weirdness in github's interface - if you delete the .jpg from the .gitattributes then technically those files stop being lfs - however, github will continue to show them as if they're LFS - they must be storing the filename with the lfs status - which I guess is safe than relying on parsing gitattributes as there may be filters other than lfs that actually end up with adding stuff to the lfs.

GiteaMirror commented

2025-11-02 04:47:25 -06:00

@lafriks commented on GitHub (Jan 21, 2019):

I don't thint gitattributes should be taken into account

@lafriks commented on GitHub (Jan 21, 2019): I don't thint gitattributes should be taken into account

GiteaMirror commented

2025-11-02 04:47:25 -06:00

@zeripath commented on GitHub (Jan 21, 2019):

Hmm, I think .gitattributes and the lfs filter is really the only thing we've really got to detect if a file is LFS or not. I suppose you could come up with another filter with a different name than the default but then you're at the point of making things so difficult for everyone that your repository is very special indeed.

I suspect for my current patchset #5787 it's probably reasonable to assume that if it looks like a pointer, just check if the LFS Oid is in that repository and if so, show it as the object.

@zeripath commented on GitHub (Jan 21, 2019): Hmm, I think .gitattributes and the lfs filter is really the only thing we've really got to detect if a file is LFS or not. I suppose you could come up with another filter with a different name than the default but then you're at the point of making things so difficult for everyone that your repository is very special indeed. I suspect for my current patchset #5787 it's probably reasonable to assume that if it looks like a pointer, just check if the LFS Oid is in that repository and if so, show it as the object.

GiteaMirror referenced this issue

2025-11-02 05:43:00 -06:00

A new subcommand named `doctor` to detect all the possible problems #4223

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#2762