Problem

It's impossible to find out what the limitations of the Git LFS program are from reading the homepage or the linked docs file.

Current user journey

1. User learns that Git LFS exists and uses "favorite search engine" to find out if it will work for their usecase.
2. User lands on the https://git-lfs.github.com/ homepage.
3. "Git LFS might work for me, but what are the limitations? The homepage doesn't mention this at all..."
4. "Let's click on Docs in the navbar, maybe that will explain the limits of the program..."
5. User lands on https://github.com/git-lfs/git-lfs/tree/main/docs?utm_source=gitlfs_site&utm_medium=docs_link&utm_campaign=gitlfs "This file also doesn't mention limitations at all..."
6. User searches on the internet to try to find out what Git LFS supports, and hopefully stumbles on https://github.com/git-lfs/git-lfs/wiki/Limitations somehow.
7. "Turns out I can use Git LFS, hooray!" or "Shame, Git LFS won't work for me!".
8. "That was a hassle finding out what the program supports!"

Better user journey

1. User learns that Git LFS exists and uses "favorite search engine" to find out if it will work for their usecase.
2. User lands on the https://git-lfs.github.com/ homepage.
3. "Git LFS might work for me, but what are the limitations?"
4. "Oh, they have a link/section explaining the limits of the Git LFS program! Let's click on the link/read the section."
5. "Git LFS will work for me!" or "Git LFS won't work for me, I need to find an alternative".

Proposed solution(s)

Option 1: Put link to git-lfs repo wiki on the homepage

Put a link to https://github.com/git-lfs/git-lfs/wiki/Limitations somewhere suitable on the homepage.

Option 2: Make a new section: :"Known limitations" on the homepage.

I like this option better, as new users can see right away if Git LFS will work for them or not.

Points to: https://github.com/git-lfs/git-lfs/releases/download/v2.0.1/git-lfs-windows-2.0.1.exe

instead of: https://github.com/git-lfs/git-lfs/releases/download/v2.0.1/git-lfs-windows-2.0.1.ext.exe

(notice .ext.exe instad of .exe at the end)

We have a Gitlab omnibus install on an arbitrary port being served by a Haproxy on 80/443 splitting traffic by subdomain. LFS was then enabled in Gitlab and stores on a network mount. Credentials are supplied by LDAP, including SSH key support. Our SSL certs are supplied by Letsencrypt.

Haproxy was initially configured to redirect http scheme to https.

Attempting to push lfs files would work for about 35 seconds (regardless of source or ping) and then fail, reporting File Already Closed for all remaining transfers. This was while using SSH with keys. I'm mildly aware that lfs uses an http(s) connection in the background when using SSH for git.

After fiddling with timeouts and cache sizes for a while, in both Haproxy and Gitlab's nginx implementation, I instead found that eliminating the http->https redirect in Haproxy solved our issue, and lfs was happy to move half a gig at once.

I'm mostly concerned that some credential handling isn't sticking to using https, or doesn't support it in the first place.

The "Same Git workflow" says:

Work like you always do on Git—no need for additional commands, secondary storage systems, or toolsets.

The statement is indeed true when using GitHub, Atlassian, GitLab, etc. but if you run your own official git server, it cannot be used as is by git-lfs, so a "secondary storage system" which is a git-lfs server is actually needed. It would be useful to mention this distinction.

Related: Since there is no official git-lfs server implementation yet, one has to dig through implementations to find one which can actually be run and supports the latest git-lfs features. I still did not find any appealing implementation. The page could set better the path/expectations for people with a standard git server.

Loading https://git-lfs.github.com/ in a browser gives me a 404 error. Oddly, curl -I https://git-lfs.github.com/ yields a 200 response.

Maybe this is just a temporary blip?

I see the following invalid url from commands like git blame: https://git-lfs.github.com/spec/v1

Can this URL please be created? Per git-lfs/git-lfs#2877 (comment) it seems the URL is intended to exist.

These lines look like they need some spacing between them so that the command example blocks are not touching each other.

Fetching source index from https://rubygems.org/
Could not verify the SSL certificate for https://rubygems.org/.
There is a chance you are experiencing a man-in-the-middle attack, but most likely your system doesn't have the CA certificates needed for
verification. For information about OpenSSL certificates, see bit.ly/ruby-ssl. To connect without using SSL, edit your Gemfile sources and
change 'https' to 'http'.

what they mean is at the top of the Gemfile in your rails application directory change
source 'https://rubygems.org'
to
source 'http://rubygems.org'

It's not immediately clear that PackageCloud needs to be setup as a repo for your linux package manager.

/cc git-lfs/git-lfs#1476

Knowing how animated graphics were generated ?

The download link on the git-lfs homepage is broken.

Update _includes/home/secondary.html ? to address issues in git-lfs/git-lfs#3181 and addressed in git-lfs/git-lfs#3193

in the Getting Started section,

• step 1 mentions to install the binaries, but git lfs install isn't an installer. (install.sh is)

• steps 2 and 3 ( git lfs track, git add, push etc) are example usage and not part of the installation.

• It might be good to move step 1 of getting started up near the blue Download button, something such as "once downloaded, git lfs needs to be configured once…

Motivation: In our instructions for example, we are trying to refer to the git-lfs docs as a prereq to doing a git clone. git lfs track for example is not needed before doing a git clone of an lfs-enabled repo.