-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
github pages serving the reference file instead of the actual binary #1342
Comments
GitHub Pages doesn't support Git LFS. This issue isn't really the place to discuss it (this repo is for the |
Sorry for the noise, I will close this issue. For the future: where is the correct place to get support for git-lfs related issues that are not specific technical issues with the client? |
Depends on the issue. Since you're asking about GitHub Pages, you'll want to hit up GitHub Support: https://github.com/contact. That said, I'll be forwarding this issue to the team, as a way to gauge interest in new features. |
M .gitattributes
I also would like this, and it seems like this was already mentioned in #791. On a more technical level, what would be required to allow public read access to the blob tracked by git-lfs? I assume that that is the blocker here, after that it's just a matter of writing a jekyll plugin that transforms some hrefs. Going with that assumption, there needs to be another API that allows for creation of unauthenticated links to the blob in question. Probably a new transfer API type would be good here. PS. While I do understand that you want to keep GitHub out of this repo, having people contact support removes the discussion, and subsequent answers, from the public. This makes it very hard to figure/find out why it doesn't work. If there is another place where a public discussion should take place, please let us know. Anyway, just some thoughts. DS. |
I'd be interested to give some feedback or use cases about this feature – I currently include video files for a book written with Asciidoc, published on GitHub Pages as HTML pages amongst others. |
Any updates? |
+1 this could really help a lot of use cases. |
Adding my +1 to the mix too! |
Another +1 here! |
Workaround: Commit and push LFS files first. Then link to LFS files according to this format:
|
The workaround mentioned by @loriBranford didn't work for me, but this did:
I can't claim any great insight here, this is the path associated with the view raw link when you are in the repo looking at the file you want to access. Entering this URL in a browser generates the download file dialog box, and I was able to successfully automate a download and install in the |
Dear jspillers, |
You should replace all the xxx things to your's |
GitHub.io does not support LFS. See git-lfs/git-lfs#1342
Replaces Git LFS tracking of images and fonts with regular git tracking using the approach suggested in [1], because GitHub Pages does not support Git LFS files (as of writing). Removing Git LFS entirely was selected over updating URLs to absolute GitHub paths (as done in [2]) as it's simpler to manage going forward. [1] git-lfs/git-lfs#3026 (comment) (not using the subsequent comment's '--renormalize' due to old Git version). [2] git-lfs/git-lfs#1342 (comment)
This is not really a git-lfs issue but a GitHub Pages implementation issue, right? |
Yes, it is. Talking to GitHub support is the best way to address this. Since this isn't a Git LFS issue, I'm going to close this. |
GithHub Pages does not support Git LFS (see [this issue][1]). Since we use *.jpg files only in the developer's documentation, the LFS tracking is removed so that the files are properly served on GitHub Pages. [1]: git-lfs/git-lfs#1342 The workflow build-test-inspect was intentionally skipped. The workflow check-style was intentionally skipped. The workflow check-release was intentionally skipped.
GithHub Pages does not support Git LFS (see [this issue][1]). Since we use *.jpg files only in the developer's documentation, the LFS tracking is removed so that the files are properly served on GitHub Pages. [1]: git-lfs/git-lfs#1342 The workflow build-test-inspect was intentionally skipped. The workflow check-style was intentionally skipped. The workflow check-release was intentionally skipped.
GithHub Pages does not support Git LFS (see [this issue][1]). Since we use *.jpg files only in the developer's documentation, the LFS tracking is removed so that the files are properly served on GitHub Pages. [1]: git-lfs/git-lfs#1342 The workflow build-test-inspect was intentionally skipped. The workflow check-style was intentionally skipped. The workflow check-release was intentionally skipped.
Local relative link doesn't work with LFS, since GitHub pages doesn't support git LFS. Related issue: git-lfs/git-lfs#1342
Local relative link doesn't work with LFS, since GitHub pages doesn't support git LFS. Related issue: git-lfs/git-lfs#1342
I have a large file I am using git lfs to track as a part of a github.io repo. When I hit the URL to access the large file I am being served what I am assuming is the tiny reference file (134 bytes) instead of the large binary.
The file that should be the large file has the following contents:
version https://git-lfs.github.com/spec/v1
oid sha256:805400bc5ba8c96f8dff29a70c88d29c0566340b063e66f62326a1d3c3ea78ae
size 110517008
It's strange because this was just working... it wasn't until I committed a new version of the large file to the repo that I started getting this behavior. git lfs untrack + git rm and then re-adding the file appears to get it to push, but when I try to access it I get the wrong file.
The file in question is: http://www.stacktact.com/dynamic_terrain_objects_demo/Demo.unity3d
The text was updated successfully, but these errors were encountered: