webclient does not support LFS

[dsteinkopf]

Hello,

I tried out gitblit's lfs support by git lfs track *.pdf and adding some files. Fine. But unfortunately I cannot view the PDFs in the webclient by clicking on the "raw" link. The only downloads the "short version" of the file (containing version ... oid ... size...) resulting in an error displayed by my local PDF view telling me this isn't a valid PDF.

Is this a bug or a feature?

Thank you very much,

Dirk

[paulsputer]

Hi Dirk, Thanks for reporting, this is fixed in #976 and merged to master in #988 on 25th Jan.
Unfortunately a bug remains (#1018) as the downloaded filename will be a hash without file extension, or incorrectly a .zip extension.

I'm half way through a fix for #1018 but been sidetracked on other things recently. I'm anticipating finishing that off later this week. Are you on a self build from master or release version?

[dsteinkopf]

Thank you very much for you answer and also for you work on gitblit. I am very happy about gitblit which I only discovered recently! Sorry for not finding the existing bug ticket - I only searched for "LFS".

I am using gitblit release 1.7.1 from https://hub.docker.com/r/jacekkow/gitblit/ which downloads gitblit-${GITBLIT_VERSION}.tar.gz. But it should not be a big deal to checkout and build the master version. Should I try (when #1018) is ready? (I subscribed to this ticket now.)

[ternet]

Hi,

I've been searching the web for a git-like vcs with large-file-support and (!) a repository-web-viewer. gitblit seemd to be the answer, but then I run into this bug. I'm looking forward to the new version.

Apart from that: support for git-annex would be a great thing.

Greetings

Tobias

[paulsputer]

@dsteinkopf This fix is now merged into master, so you can go ahead and try.

@ternet originally I was looking at git-annex but the gitLFS draft spec was released just in time for me to implement that instead. You'll notice I've called it "Filestore" in Gitblit, intentionally to keep it generic from a users perspective. It will be interesting to see how much traction annex will continue to have given GitHub is leading gitLFS, though I notice GitLab is supporting both. A PR may be welcome though the challenge would be to leverage as much of the Filestore code as possible as the federation support needs to be included soon.

[dsteinkopf]

Seems to work with current master version (caa660d).
Thank you very much,

(Unfortunately when viewing a PDF one does not see the original file name anymore, but I think that is not avoidable.)

[paulsputer]

(Unfortunately when viewing a PDF one does not see the original file name anymore, but I think that is not avoidable.)

@dsteinkopf I'm not sure I follow. Where are you not seeing the original file name where you were before? This merged fix downloads the file with the original filename though depending on your browser settings you may find it automatically opens the file.

[dsteinkopf]

Don't worry too much: At first I see the filename of course. Then I click on it, then I am redirected to a URL ending in the hash code of the file (I think). The browser (Chrome) now displays the file contents. But in the address line I only the the rediected URL but not the original filename.... Not a too big problem. (Don't waste your time on that at this moment.)

[paulsputer]

Ah right yes, in this commit the URL is not a shareable one and ends with wicket markup, the commit before did provide a shareable URL but did not provide any filename or extension and ended with /lfs/{hash} .

When gitLFS sends the blob to us there is no direct access to the filename. it can be figured out, but as you say, it's not a big problem hence I didn't implement that part as this is just until JGit suppots LFS which by the looks of things they've just released support for it so at some point we might update to that. :)