git-lfs push with SSH should give better locking advice

[KyleFromKitware]

Describe the bug When I use git-lfs to push to a pure-SSH endpoint, I see the following message:

Locking support detected on remote "local/ssh". Consider enabling it with:
  $ git config lfs.https://localhost/root/lfs-test.git/info/lfs.locksverify true

I didn't give it this URL anywhere, and it's not even valid in my configuration. With a pure-SSH connection, git-lfs should not even think about connecting via HTTP (I noticed that git lfs env also displays this phony HTTP endpoint.)

To Reproduce Steps to reproduce the behavior:

1. Push to a pure-SSH endpoint
2. See the output

Expected behavior git-lfs should either know that locking is supported by the SSH endpoint, or at least give me the correct URL to enable locking.

System environment Ubuntu 20.04, connected to an under-development GitLab server (with https://gitlab.com/KyleFromKitware/gitlab-shell/-/tree/git-lfs-transfer applied to gitlab-shell) with pure-SSH support.

git config -l:

user.name=Kyle Edwards
[email protected]
core.editor=vim
merge.dpkg-mergechangelogs.name=debian/changelog merge driver
merge.dpkg-mergechangelogs.driver=dpkg-mergechangelogs %O %A %B %A
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
filter.lfs.clean=git-lfs clean -- %f
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
branch.master.remote=local/ssh
branch.master.merge=refs/heads/master
lfs.repositoryformatversion=0
remote.local/ssh.url=ssh://git@localhost:2222/root/lfs-test.git
remote.local/ssh.fetch=+refs/heads/*:refs/remotes/local/ssh/*

Output of git lfs env

git-lfs/3.4.0 (GitHub; linux amd64; go 1.21.3; git ac5af606)
git version 2.25.1

Endpoint (local/ssh)=https://localhost/root/lfs-test.git/info/lfs (auth=none)
  SSH=git@localhost:/root/lfs-test.git
LocalWorkingDir=<REDACTED>/lfs-test/src
LocalGitDir=<REDACTED>/lfs-test/src/.git
LocalGitStorageDir=<REDACTED>/lfs-test/src/.git
LocalMediaDir=<REDACTED>/lfs-test/src/.git/lfs/objects
LocalReferenceDirs=
TempDir=<REDACTED>/lfs-test/src/.git/lfs/tmp
ConcurrentTransfers=8
TusTransfers=false
BasicTransfersOnly=false
SkipDownloadErrors=false
FetchRecentAlways=false
FetchRecentRefsDays=7
FetchRecentCommitsDays=0
FetchRecentRefsIncludeRemotes=true
PruneOffsetDays=3
PruneVerifyRemoteAlways=false
PruneRemoteName=origin
LfsStorageDir=<REDACTED>/lfs-test/src/.git/lfs
AccessDownload=none
AccessUpload=none
DownloadTransfers=basic,lfs-standalone-file,ssh
UploadTransfers=basic,lfs-standalone-file,ssh
GIT_EXEC_PATH=/usr/lib/git-core
git config filter.lfs.process = "git-lfs filter-process"
git config filter.lfs.smudge = "git-lfs smudge -- %f"
git config filter.lfs.clean = "git-lfs clean -- %f"

Additional context Any other relevant context about the problem here.

[bk2204]

Hey,

I think this probably should be fixed. I have some SSH-related improvements in a recent PR which should be easy to include the appropriate URL.

Note that the Endpoint URL exists because in git lfs env it's not known whether the endpoint supports the native SSH protocol or not and we don't want to attempt to connect to find out. Thus, both the HTTPS and SSH protocols are listed.

[KyleFromKitware]

Note that the Endpoint URL exists because in git lfs env it's not known whether the endpoint supports the native SSH protocol or not and we don't want to attempt to connect to find out. Thus, both the HTTPS and SSH protocols are listed.

Thanks for the context. If #5555 gets merged, and the endpoint is configured as native SSH only, then git-lfs should definitely not list a made-up HTTPS URL.