LFS does not use a SUBSTed Path in every place

[rhoellwarthwork]

I'm using git lfs as Part of the git for Windows Installation v 2.27.0. It's git lfs 2.11 - see below the output of git lfs env for details.

Im using the dos SUBST command to redirect a subdirectory to the driveletter D:. Today I cloned an empty repository and wanted to track "*.docx" files and got the following error:

/d/repos/PROD/TEST/test.push_test_wg_git_lfs (master)
$ git lfs track "*.docx"
Current directory "D:\repos\PROD\TEST\test.push_test_wg_git_lfs" outside of git working directory "C:\Users\Public\Documents\subst_D\repos\PROD\TEST\test.push_test_wg_git_lfs".

I cd'ed to the "real" directory and repeated the command successfully. After that cd'ed back to the D:-version of the folder an could work with lfs flawlessly. (git add, git commit, git push - all worked like expected).

When I do a git lfs env I see that all directorys are located on the D:-Drive. Only the LocalWorkingDir is located on C:

$ git lfs env
git-lfs/2.11.0 (GitHub; windows amd64; go 1.14.2; git 48b28d9)
git version 2.27.0.windows.1

Endpoint=https://xxxxxxx/test/test.push_test_wg_git_lfs.git/info/lfs (auth=none)
SSH=git@xxxxxxx:test/test.push_test_wg_git_lfs.git
LocalWorkingDir=C:\Users\Public\Documents\subst_D\repos\PROD\TEST\test.push_test_wg_git_lfs
LocalGitDir=D:\repos\PROD\TEST\test.push_test_wg_git_lfs.git
LocalGitStorageDir=D:\repos\PROD\TEST\test.push_test_wg_git_lfs.git
LocalMediaDir=D:\repos\PROD\TEST\test.push_test_wg_git_lfs.git\lfs\objects
LocalReferenceDirs=
TempDir=D:\repos\PROD\TEST\test.push_test_wg_git_lfs.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=D:\repos\PROD\TEST\test.push_test_wg_git_lfs.git\lfs
AccessDownload=none
AccessUpload=none
DownloadTransfers=basic,lfs-standalone-file
UploadTransfers=basic,lfs-standalone-file
GIT_EXEC_PATH=C:/Program Files/Git/mingw64/libexec/git-core
GIT_SSH=C:\Program Files (x86)\WinSSHTerm\tools\plink.exe
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"

My OS is Windows 10 1709 (Build 16299.2045). I tested it also on Win 10 1909 (Build 18363.1016) - same error.

I don't think this is an intended behavior. At least it is not the behavior I did expect.

[bk2204]

Hey,

I'm almost certain that this is the same problem as in #4012. Git LFS is written in Go, and Go lacks a cross-platform function to canonicalize paths. Since we read data from Git and Git canonicalizes paths, they look different and we can't detect that they're the same location. A bug report about this has been to golang/go#37113, and we'll fix it in Git LFS when upstream decides they'd like to implement the required functionality.

[rhoellwarthwork]

Moin!
Thanks for looking into my problem. I'll watch also the go-Issue.

[bk2204]

Could you check the PR in #4418 and see if it fixes your problems? If you need a binary, you should be able to download one from the Actions artfiacts.

[douglaslassance]

I am not sure if you'd expect what I described in #4417 to work, but it did not fix it for me.

• Installed the WIndows installer from the articfacts.
• Re-cloned the repo to be sure.
• Re-ran git lfs install.
• Re-subst the folder.
• Tried to lock a file.

Getting Rel: can't make <subst\path> relative to <actual\path>.

[bk2204]

If you're using the Git LFS installed with Git for Windows, you either need to remove those binaries or reinstall Git for Windows with Git LFS in order to have the new version take effect. The Git LFS installer doesn't override the Git for Windows binaries at the moment.

[douglaslassance]

Indeed, and once I've re-installed everything, it worked. I was able to lock files from the subst directory. Very cool, thank you.

[bk2204]

Great. I'll open the PR up for review. Thanks for testing; I'm excited that I managed to finally put some useful Windows code together and that we can finally fix this.

[douglaslassance]

How does one check the release status of such a fix?
When I saw that v2.13.3 was released on March 26, I naively assumed the fix was going to be in there.

[chrisd8088]

The specific changes and PRs included in any release are generally listed in the notes, for example, on v2.13.3's release page. Individual releases are listed by tag. And major and minor releases are more fully documented in the change log.