git-lfs not registered in environment vars causes CLI issues

[zezba9000]

• [x] I was not able to find an open or closed issue matching what I'm seeing

Setup

git version 2.12.2.windows.1
built from commit: 212247dd6345c820deeae61fcdf2f10cea10525a
sizeof-long: 4
machine: x86_64

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

Microsoft Windows [Version 10.0.14393]
Win10 x64

• What options did you set as part of the installation? Or did you choose the
  defaults?

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

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

* git-lfs is not installed and is using the version packaged with Git for Windows *

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

* Git-It-GUI (aka invoking "git clone" via CLI in C#): github.com/reignstudios/Git-It-GUI*

• 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.

** git clone <http://my-GitLab-url> **

• What did you expect to occur after running these commands?

* it to clone a repo and checkout git-lfs files *

• What actually happened instead?

* it didn't checkout git-lfs ptr files or setup git-lfs repo filters correctly. (it does if I install git-lfs manually as this registers it in the Windows environment vars) *

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

* Sorry I can't but should be the same on any git-lfs repo *

[zezba9000]

I would recommend not shipping git-lfs with git for windows. It causes confusions when trying to install git-lfs 2.0.2 for example and git bash reports a different version not used when invoke git over CLI.

[shiftkey]

I'm not seeing the config values we define in the install script appear after installation:

$ git --version
git version 2.12.2.windows.1

$ git config -l --system
credential.helper=manager

$ git config -l --global
fatal: unable to read config file 'C:/Users/shiftkey/.gitconfig': No such file or directory

@dscho is there something we've not done correctly with the packaging?

@zezba9000 as a workaround, you can setup of the filters yourself, without reinstalling Git LFS:

$ git lfs install
Updated git hooks.
Git LFS initialized.

$ git config -l --global
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f

[zezba9000]

@shiftkey That workaround wont do anything if "git-lfs.exe" isn't found with a standard C# "Process.StartProcess("git-lfs", "version");" call. The .gitconfig file is not the problem.

In short git-lfs that comes packaged with git for windows isn't in the path like a normal git-lfs install. Also if it was this would just cause dependency order ambiguity if the user installed git-lfs manually (which makes the most sense anyway).

[shiftkey]

git-lfs.exe is located at C:\Program Files\Git\mingw64\bin which is on my PATH after installing.

[zezba9000]

I'll write a very simple C# console app to reproduce and illustrate the problem later today. (that does a git clone from an lfs repo).
Maybe it will help to figure out whats wrong.

[shiftkey]

The .gitconfig file is not the problem.

I'm probably being unclear here, but the problem as I see it is that the Git for Windows packaging process isn't setting the filters that Git LFS needs. That's all the installer is doing when you run it.

By default it should be applied to the global Git configuration, but with Git for Windows we want this to be done for all users - so it should be applied to the system configuration.

With neither of those places having the expected configuration, I wonder if something's changed with the packaging that we've overlooked.

[zezba9000]

I understand what you're saying and maybe I'm wrong about the cause of the issue being a Path one. So all I know at this point is invoking git-lfs via a C# process object doesn't work (with the git filters in the config etc).

I will confirm this later today. Maybe I overlooked something in the mix of things.

[zezba9000]

So it doesn't work and git-lfs is not in the windows path. Git bash works BUT not windows cmd.

Here is my .gitconfig

[user]
    email = [email protected]
    name = Andrew Witte
[filter "lfs"]
    smudge = git-lfs smudge -- %f
    process = git-lfs filter-process
    required = true
    clean = git-lfs clean -- %f

So a simple app like this doesn't work:

namespace TestGitLfsInvoke
{
    class Program
    {
        static void Main(string[] args)
        {
            using (var process = Process.Start("git-lfs", "version"))
            {
                process.WaitForExit();
            }
        }
    }
}

Here is the git bash working image: Bash
Here is the cmd NOT working image: cmd
NOTE: if I install git-lfs from git-lfs link, cmd and C# apps work.

Also you're right that the .gitignore settings don't default correctly and is probably why cloning a git-lfs repo doesn't work. However this isn't the only bug I'm having.

[shiftkey]

Okay, I think I've spotted the issue. Try this command:

git lfs version

Git for Windows is smart enough to resolve the custom lfs command without it needing to be on your PATH, and this follows the convention about how other programs extend Git (like git svn).

EDIT: the path to git-lfs.exe is added for Git Bash and Git CMD, but not for plain Windows Command Prompt. That's the root cause.

[zezba9000]

That would work if the installer gets fixed. So as you pointed out because the .gitconfig file isn't being setup correctly git clone will not work in the windows cmd with lfs files.

In short to close this issue the windows git installer needs to add these to the .gitconfig file so git clone via the windows cmd or cli work correctly.

[filter "lfs"]
    clean = git-lfs clean -- %f
    smudge = git-lfs smudge -- %f
    process = git-lfs filter-process
    required = true

[shiftkey]

In short to close this issue the windows git installer needs to add these to the .gitconfig file correct so git clone via the windows cmd or cli work correctly.

:thumbsup: let's see if @dscho has any thoughts on the original issue

[dscho]

$ git config -l --global

Since Git LFS is installed system-wide, it is the system config that should have been adjusted (i.e. git config -l --system). But I just tested this here and it seems that something did not work as planned.

git-lfs.exe is located at C:Program FilesGitmingw64bin which is on my PATH after installing.

It should be in C:\Program Files\Git\mingw64\libexec\git-core, though, and the PATH should not include either directory, but C:\Program Files\Git\cmd instead (unless you changed the default on the Path Option page of the installer).

using (var process = Process.Start("git-lfs", "version"))

That is the wrong executable to start. If you run any Git subcommand, whether provided by core Git or whether it is an add-on by a third party, you need to call it in the "undashed" form: Process.Start("git", "lfs version") would be correct.

[shiftkey]

But I just tested this here and it seems that something did not work as planned.

I'll get a Git SDK environment prepared and see if I can recreate this issue on my side.

It should be in C:\Program Files\Git\mingw64\libexec\git-core

I can give you a PR for this - that's an easy change.

[dscho]

Thanks! I commented there.

[dscho]

And I already pushed a fix: https://github.com/git-for-windows/build-extra/commit/115b9f5b88ff60af19628262833b42cd7b6cd852

Please note that the ticket has an incorrect title (it is the config settings, not the environment variables, that are missing), that's what fooled me into believing that other issues were more critical.

[dakotahawkins]

As mentioned in https://github.com/git-for-windows/build-extra/pull/141 I think this is incorrect advice (at least for git-lfs):

That is the wrong executable to start. If you run any Git subcommand, whether provided by core Git or whether it is an add-on by a third party, you _need_ to call it in the "undashed" form

The LFS filters themselves call git-lfs directly and the reason is to avoid an extra fork of git.exe. IIRC this wasn't always the case, and was "fixed" many versions ago to help avoid an extra costly process creation on Windows.

You'll probably find all kinds of scripts all over the place utilizing the same "calling convention" for LFS, and while I can't speak for cmd.exe or powershell, I think at least in git bash git lfs and git-lfs shouldn't potentially refer to different LFS executables.

[dscho]

@dakotahawkins thanks for the reality check, and even more for the Pull Request! This is what makes Open Source what it is: the contributors who participate and push the project forward.

[zezba9000]

Just to confirm, works great in git-bash and CLI / cmd :)