Git LFS 2: Poor performances of 'lfs locks' on Windows command line

[SRombauts]

Poor performances of 'lfs locks' on Windows command line (vs Windows Subsystem for Linux) #2616

I am seeing very poor performances of the "git lfs locks" command:

• it takes +3 seconds, sometimes +5s on the Windows command line (as well as on the Windows Git Bash command line.
• by comparison, under the Windows Subsystem for Linux "Bash Ubuntu" (or under Linux) it takes repeatedly around 1s

[SRombauts]

Seems that credentials could be the culprit! You can not see it here, but roughly half of the time seems to be spent between the lines "creds: git credential fill" and "Filled credentials for..."

$ time GIT_TRACE=1 git lfs locks
09:00:18.037537 git.c:572               trace: exec: 'git-lfs' 'locks'
09:00:18.037537 run-command.c:626       trace: run_command: 'git-lfs' 'locks'
trace git-lfs: run_command: 'git' version
trace git-lfs: run_command: 'git' config -l
trace git-lfs: creds: git credential fill ("https", "github.com", "SRombauts/UE4GitLfs2FileLocks.git")
trace git-lfs: Filled credentials for https://github.com/SRombauts/UE4GitLfs2FileLocks.git
trace git-lfs: HTTP: GET https://github.com/SRombauts/UE4GitLfs2FileLocks.git/info/lfs/locks
trace git-lfs: HTTP: 200
trace git-lfs: HTTP: {"locks":[],"next_cursor":""}

real    0m2,847s
user    0m0,000s
sys     0m0,000s

I will be unable to investigate any more before this evening, but it now seems to me that this that LFS is not the culprit here.

Things I would like to test before closing this issue:

1. try and compare with SSH URLs (AnswerHub: try SSH instead)
2. try with GCM_TRACE=1 (Git-Credential-Manager)
3. try disabling the Git-Credential-Manager-for-Windows: it is a .NET process, so that could be the root problem

[technoweenie]

The problem is that to prompt for, and save a valid password, LFS has to do the following:

• Run git credential fill, which runs the command specified by the credential.helper git config key. This either pulls the pwd from the credential helper, or prompts you if the helper doesn't have one.
• Run git credential approve if the password works, which calls the credential helper.

Now, repeat this process for every URL that LFS requests. LFS v2.3.3 enables password caching for a single git lfs command, meaning this will happen only once in the lifetime of a git lfs command.

[ImmotionGroup]

Hi, We're experiencing this as well. Is there any thoughts to a possible resolution to the performance issue?