Prioritize git environment variables from parent process

[monder]

Summary

If there are any ENV variables specified for the parent process - use them.
The main reason for this is that our CI uses GIT_SSH_COMMAND env to specify ssh keys to use for cloning and not via ssh-agent.
For example for github the user is always git@ and it is obviously possible to make fake users in ssh config, etc...
But there should be an option to customize GIT_SSH_COMMAND directly.

Test plan

Before:

$ GIT_SSH_COMMAND="ssh -i ~/git.pem -F /dev/null" yarn install
yarn install v0.27.5
[1/4] Resolving packages...
[2/4] Fetching packages...
error Command failed.
Exit code: 128
Command: git
Arguments: clone git@github.com:monder/test.git /home/monder/.cache/yarn/v1/.tmp/f13ca8a124faac37abd837f21d8375bf
Directory: /tmp/test
Output:
Cloning into '/home/monder/.cache/yarn/v1/.tmp/f13ca8a124faac37abd837f21d8375bf'...
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

After:

$ GIT_SSH_COMMAND="ssh -i ~/git.pem -F /dev/null" yarn install
yarn install v0.27.5
[1/4] Resolving packages...
[2/4] Fetching packages...
warning fsevents@1.1.2: The platform "freebsd" is incompatible with this module.
info "fsevents@1.1.2" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
Done in 108.73s.

[kaylie-alexa]

Looking at this previous PR (#3633), it looks like your changes may reintroduce bugs. Can you try appending the args to GIT_SSH_COMMAND instead of overriding them?

[monder]

The variables will be overridden only if they are defined in shell, which is not a default. By default all three variables will be appended to the env as previously. I've tested it with the repo specified in #3633 and it works.
Also I cannot make any assumptions to merge GIT_SSH_COMMAND - it may be pointing to a wrapper script that is not even ssh.

[kaylie-alexa]

gotcha, thanks for explaining and testing the previous issue :) Yeah I guess at this execution level, the user's intent is well defined. If ci passes, looks good to me!

[BYK]

I'm still a bit concerned about this reverting the freeze fixes but let's wait and see if we get any complaints.