vcpkg_from_git (SSH URL) affected by user environment

[christophe-calmejane]

Describe the bug
The vcpkg_from_git command is affected by the user's environment. Based on the current running shell and the installed git version, installing a port might succeed or fail.
In my case, I'm running vcpkg either from cygwin, WSL or gitbash, and I don't get consistent results depending whether I have git installed or not, and which version of git.
The issue with vcpkg_from_git when using a SSH type URL, is that git must call SSH for the transport. If vcpkg detects that the system already have a suitable version of git installed (>= 2.26), it doesn't download the portableGit version and uses the system version of git. Probably due to PATH env cleanup or other env var being wiped by vcpkg execute_process call, calling git can cause errors like: ssh: No such file or directory
If my system does't have git installed or a git version too old (< 2.26) then vcpkg will automatically install portableGit and use this version, and the port will install correctly.

Environment

• OS: Windows
• Compiler: Doesn't matter

To Reproduce the environment issue
Steps to reproduce the behavior:

1. Fully wipe vcpkg (especially downloads folder)
2. Open a cygwin terminal with a git version >= 2.26 installed
3. Create a port myPort with just the following lines

	find_program(GIT NAMES git git.cmd)
	message(FATAL_ERROR "Found git: ${GIT}")

4. ./vcpkg install myPort
5. Observe in the error log that the git being used is the installed one

Alternatively instead of using cygwin, you can create a temporary folder anywhere, create a git.cmd file inside that just contains this line:

echo "git version 2.29.2"

Then add this folder to your path: export PATH=pathToFolder:$PATH and run vcpkg install

To Reproduce the actual port error

1. Fully wipe vcpkg
2. Open a cygwin terminal with a git version >= 2.26 installed
3. Create a port myPort with just the following lines (replace placeholders with something valid)

	vcpkg_from_git(OUT_SOURCE_PATH SOURCE_PATH URL git@mygitserver:mylibrary.git REF myref)

4. ./vcpkg install myPort
5. Observe in the error log: ssh: No such file or directory

Expected behavior
As vcpkg aims to not be affected at all my the user environment, I expect this to happen in all possible scenarios (cygwin, WSL, gitbash, or any other console subsystem) and be consistent. In case the user installed a corrupted or misbehaving git version, I expect vcpkg to run consistently.
I would expect vcpkg to always download and use it's own version of git, whether it found a suitable one or not in the system (that might or might not work correctly, even if it returned a suitable version from the git --version call).

[dg0yt]

Somewhat related to that particular problem, I would like point out that using tools from cygwin with vcpkg will sooner or later lead to mixing programs with different runtimes (Cygwin, MSYS2) which is discouraged (at least by MSYS2, forwarded in https://github.com/microsoft/vcpkg/blob/master/docs/users/mingw.md#how-to-avoid-mixing-different-installations).
So vcpkg might need to be more careful with which builds of git it accepts, in addition to the version. (Perhaps check for cygwin/msys*.dll?)

[christophe-calmejane]

Well, since vcpkg automatically downloads and use it's own portableGit version if it couldn't find a suitable git version the first time it's run, I don't see any good reason for not always use it's own version of git for consistency.

Let's just imagine that someone installs the latest version of git which contains a breaking change (won't probably happen, but we never know), or a huge bug. Now that person installs a fresh vcpkg, and run it to install a port. Since it's the first run, vcpkg will check for the installed git version and will be happy with the one it found in the system.
Now that person will report a bug (caused by his version of git) that nobody here will be able to reproduce because even for the same commitID of vcpkg, the system is different.

If everybody uses the same version of git for a given commitID of vcpkg, a lot of errors could be prevented. And I'm not even talking about mixing cygwin/msys2/powershell/wsl/whatever, just basic system installation for different users.
Just my thought.

[christophe-calmejane]

I would add that msys2 and cmake is already forced to vcpkg internal version, even if another version is already installed. I'm just suprised it's not the case for git... or maybe it was supposed to be the case and it's just a bug in the scripts.

[dg0yt]

FTR, for CMake and Ninja, there is already an variable to opt-in system binaries: VCPKG_FORCE_SYSTEM_BINARIES.

[christophe-calmejane]

Hi,

any progress on this issue?

[PhoebeHui]

Related to issue #9109.

[christophe-calmejane]

Well, not entirely related.
Since the ticket you linked was created, and as @dg0yt noted, the VCPKG_FORCE_SYSTEM_BINARIES variable was created to prevent vcpkg from using system binaries like cmake and ninja so cygwin won't interfere.

So I think that git should be added to the list of binaries that follow VCPKG_FORCE_SYSTEM_BINARIES rules.

[strega-nil-ms]

I agree with @christophe-calmejane here; we should only use git from the system if we get VCPKG_FORCE_SYSTEM_BINARIES set, imo. @ras0219, you have opinions?

[ras0219]

I think forcing our own copy of git would be ok if we do more to reduce its size

[christophe-calmejane]

Hi,

any progress on this issue?

[strega-nil-ms]

@ras0219 if my understanding is correct, we could use our own git iff we can shrink the download from 40MB, right?

[christophe-calmejane]

Well, why not let the end user decide?
I would always prefer having to download 40MB once (less than 1 second), than not being able to build any port due to incompatible environment.
Having an option letting me decide is better than not working I think :)

[strega-nil-ms]

I agree, fwiw; I would appreciate a --force-nonsystem-binaries or something.

[christophe-calmejane]

I just made a simple PR (microsoft/vcpkg-tool#138) fixing the issue, and preventing future similar issues (like the one we just had with CMake breaking end-of-line). Let's hope it's accepted :)