Git LFS image linking not possible

[diondokter]

• 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.

[zeripath]

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?

[diondokter]

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)

[zeripath]

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.

[diondokter]

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.

[zeripath]

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

[diondokter]

A normal link is:
'[link text](link url)'.
To show an image you do it like a link, but with an exclamation mark.
''

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

[zeripath]

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]

• 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]

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

[diondokter]

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!

[zeripath]

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]

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

[diondokter]

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.

[zeripath]

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.

[lafriks]

I don't thint gitattributes should be taken into account

[zeripath]

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.