$ git --version --build-options
git version 2.16.1.windows.4
cpu: x86_64
built from commit: ef6d451bbfef86a529ebf12620289e0f15a93d8e
sizeof-long: 4
$ cmd.exe /c ver
Microsoft Windows [Version 10.0.16299.248]
# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt
Editor Option: VIM
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled
None
Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other
What commands did you run to trigger this issue? If you can provide a
Minimal, Complete, and Verifiable example
this will help us understand the issue.
Installer
It would be nice if installing Git for Windows with git-lfs is sufficient to have LFS support in VIsual Studio.
Git for Windows installs git-lfs to c:\Program Files\Git\mingw64\bin\git-lfs.exe, without git-lfs.exe being available on the path. While this works for standalone Git installation, this doesn't work for Visual Studio which has its own Git installation and cannot find git-lfs. Therefore currently it is required to still install git-lfs using the standalone installer (or put git-lfs in the path otherwise)
N/A
While this works for standalone Git installation, this doesn't work for Visual Studio which has its own Git installation and cannot find git-lfs.
This behaviour was changed a while ago, https://github.com/git-for-windows/build-extra/pull/141 is the context, and I'll point out this comment:
This prevents an issue where the user may have an older version of LFS
installed by itself and 'git-lfs' finds that version while 'git lfs' finds
the bundled version.
I'll also let @dscho chime in and see if he knows anyone on the VS team who look after the Git integration to see if they can provide any additional help.
@shiftkey thank you for explaining the reasoning. That's precisely what my thinking was, too.
As to Visual Studio supporting Git LFS: If I remember correctly, the official Git LFS installer from the Git LFS project installs Git LFS into the PATH, and that should address your concerns.
I deem this ticket independent of Git for Windows itself.
This prevents an issue where the user may have an older version of LFS installed by itself and 'git-lfs' finds that version while 'git lfs' finds the bundled version.
But this is the current behavior. If I have Git for Windows with Git LFS installed and also the standalone Git LFS installer, git lfs will use LFS version shipped with Git for Windows, while git-lfs will use the version from the standalone installer from cmd.exe. It will use the version from Git for Windows for both commands in a Git bash shell though, as mingw32\bin is on the path there. So behavior is currently inconsistent between different shells.
Using the standalone Git LFS installer puts git-lfs on the PATH, and is what we're using currently for getting LFS support in Visual Studio. But it would be nice if we can use the Git LFS version shipped with Git for Windows.
@pascalberger I understand your concerns. In your scenario, I would highly recommend not using Git for Windows' embedded Git LFS, but only the Git LFS installed by the official Git LFS installer.
@pascalberger unless you have an idea how we can make your desired feature work: we cannot add mingw64\bin to the PATH, as it has too much stuff in it that we do not want to expose to the user. For example, this addition would override find and sort, breaking all kinds of Windows scripts...
I'll keep this ticket open for a couple of days in the hope that you can come up with a solution other than what I suggested.
@dscho Would it be possible to add a symlink for git-lfs.exe to the bin path which links to the exe in the mingw64\bin path? Or how is it done for git.exe?
@pascalberger for git.exe, there is a wrapper in cmd\git.exe which simply calls mingw64\bin\git.exe after setting up a couple of environment variables. We could of course do the same for git-lfs.exe, for which we would most likely have to add some code here (imitating the git.exe case to a certain extent).
And then we would need to hard-link/copy the wrapper to git-lfs.exe by calling CopyBuiltin(AppDir+'\cmd\git-lfs.exe'); probably at the same location where the builtins are hard-linked/copied, but guarded by an if IsComponentSelected('gitlfs') then ....
We would then also have to take care of deleting that file at uninstall time, most likely it will suffice to add it to the [UninstallDelete] section.
@pascalberger how about giving it a try?
@dscho I've taken over the task of @pascalberger and tried to adjust the wrapper and the installer. I've created two pullrequests git-for-windows/MINGW-packages#22 and git-for-windows/build-extra#173
I was able to compile the wrapper and test it. But for the installer I'm not sure, if I'll succeed. I'll do my best and will let you know 馃槃...
Thank you! @stffabi!
@dscho thanks so much for merging the changes. I was just able to compile the new installer and test it. Unfortunately it seems like the CopyBuiltin currently doesn't work as we both expected.
On line L1590 for newer windows versions the target of the hardlink is git.exe. Therefore this won't work for the git-lfs case. Sorry for that, but I've just seen that the second you've merged...
Is this the intended behaviour or should this case also be hardlinked to git-wrapper.exe? Or was here the intention to only use the git-wrapper.exe in the fallback case where normal copies of the file will be created and to minimize the used disk space there?
On line L1590 for newer windows versions as target for the hardlink git.exe will be used. Therefore this won't work for the git-lfs case
But it is bin\git.exe that is used. That should be a copy of the Git wrapper itself...
(Note the difference between bin\git.exe, which is installed only for legacy purposes, and mingw64\bin\git.exe, which is the real git.exe.)
Okey, but then installer seems to use the wrong destination.
Line 1590: LinkCreated:=CreateHardLink(FileName,AppDir+'\{#MINGW_BITNESS}\bin\git.exe',0);
The resulted hardlink would map to mingw64\bin\git.exe and therefore the real git.exe.
So we should change the line to: LinkCreated:=CreateHardLink(FileName,AppDir+'\bin\git.exe',0);
Oh, you're right! Darn, my brain is rotten today. I'll fix it up.
Please be sure to review the code of conduct and be respectful of other users. cc/ @git-for-windows/trusted-git-for-windows-developers
Thanks @sentiment-bot! I am sorry 馃槃
@dscho I may create another PR for this if you would like, I'm just testing the change :)
Oh, I have the change, too...
https://github.com/git-for-windows/build-extra/compare/master...dscho:fix-git-lfs-hardlink
Great, thanks then I'll let you merge yours :)...
Could you give this a quick glance-over?
Now it is even a PR: https://github.com/git-for-windows/build-extra/pull/174
Oh, and if you could test it, that would be awesome and give me the time to look at two other tickets... 馃槉
Sure, I'll let you know the results of my test.
@stffabi thank you so much!
@dscho you're welcome. I've left some comments directly on the PR.