git commandline can't find libraries about chocolatey-packages

[alexchandel]

It's probably worth it to test portable packages only on systems with clean PATHs.

[pedrofernandesfilho]

I have this problem in version 2.7.1. In Windows 10 and 8.1.

[ferventcoder]

Thanks. If you have a potential fix for this, I would welcome it. Almost all of my locations for testing already have git installed.

[alexchandel]

@ferventcoder Let me try it on a VM...

[alexchandel]

@ferventcoder Still present on 2.7.1 for me.

Given that contents of tools/bin are just:

bash.exe
bash.exe.ignore
git.exe
sh.exe
sh.exe.ignore

and that analyzing it in Dependency Walker shows only Win32 dependences, git.exe must be using its executable path to dlopen the DLLs in tools/mingw64/bin. However what's strange is that it's linked against these at all when there are perfectly good copies in tools/usr/bin/msys-*.

[alexchandel]

@ferventcoder AHAH found it. The problem is our shim. There are four binaries called git.exe, at bin/git.exe, cmd/git.exe, mingw64/bin/git.exe, and mingw64/libexec/git-core/git.exe. Shims to any but the last will work. We create shims for all files ending in git.exe, which means we create 4 shims, and the last one is what remains. So we always luck out. The solution is to create a shim only for cmd/git.exe (or any of the three working exes).

[alexchandel]

@ferventcoder While we're at it, can we add a shim for the /git-bash.exe as well?

[ferventcoder]

Ah, sweet! Yeah, that sounds like the right approach.

Where is the git-bash.exe at?

[alexchandel]

It's in the root of the archive (e.g. next to /bin and README.portable) and gets unzipped to something like git.commandline/tools/git-bash.exe

[alexchandel]

Would this do it?

  if (!($file.FullName -match '\\cmd\\git.exe$|\\git-bash.exe$|ssh[^\\]*$' )) {

[alexchandel]

Actually we should eliminate the ssh ones. They conflict with win32-openssh.