[Bug] Installer should Respect transport protocol (git settings)

[aetonsi]

Bug Report

Current Behavior

Currently the installer (at least the ps1 script for windows) tries to install scoop by cloning the repo only via HTTPS:

# ...
$SCOOP_PACKAGE_GIT_REPO = "https://github.com/ScoopInstaller/Scoop.git"
# ...
git clone -q $SCOOP_PACKAGE_GIT_REPO $SCOOP_APP_DIR

If the HTTPS transport protocol is disabled in the git configuration of a user/system, the installer breaks.

Expected Behavior

The installer should try to fallback to SSH.

Additional context/output

This is my installer output:

PS> irm get.scoop.sh | iex
Initializing...
Downloading ...
fatal: transport 'https' not allowed
fatal: transport 'https' not allowed
Creating shim...
Resolve-Path : Cannot find path 'C:\Users\u6\scoop\apps\scoop\current\bin\scoop.ps1' because it does not exist.
At line:309 char:21
+     $relativePath = Resolve-Path -Relative $path
+                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : ObjectNotFound: (C:\Users\u6\scoop\a…rrent\bin\scoop.ps1:String) [Resolve-Path], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.ResolvePathCommand
Resolve-Path : Cannot find path 'C:\Users\u6\scoop\apps\scoop\current\bin\scoop.ps1' because it does not exist.
At line:311 char:21
+     $absolutePath = Resolve-Path $path
+                     ~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : ObjectNotFound: (C:\Users\u6\scoop\a…rrent\bin\scoop.ps1:String) [Resolve-Path], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.ResolvePathCommand
Adding ~\scoop\shims to your path.
Scoop was installed successfully!
Type 'scoop help' for instructions.

Running git config --get-regexp "protocol\..*" on a system could return something like this:

protocol.http.allow never
protocol.https.allow never
protocol.git.allow never
protocol.file.allow never
protocol.ssh.allow always

... or git config --get protocol.https.allow:

never

... means that HTTPS cannot be used to clone repos.
The actual capability of cloning via HTTPS could be also determined by the git config value protocol.allow, if set, or the env variable GIT_PROTOCOL_FROM_USER if the value is user.
See here: https://git-scm.com/docs/git-config#Documentation/git-config.txt-protocolallow

Possible Solution

Instead of trying to parse the git configuration, which could be cumbersome, a check like !$? -or $LASTEXITCODE -eq 128 right after the git clone command should be sufficient.
In case of error you can then proceed with cloning via SSH (git@github.com:ScoopInstaller/Scoop.git).

System details

Windows version: 11 (Microsoft Windows [Version 10.0.22621.1702])

OS architecture: x64

PowerShell version: 7.3.4

Additional software: git version 2.40.1.windows.1, OpenSSH_for_Windows_8.6p1, LibreSSL 3.4.3

Scoop Configuration

{
  "last_update": "2023-05-30T15:49:12.9478507+02:00"
}

[chawyehsu]

This could be counted as a regression of #40 in which initialization with git was introduced.

Instead of trying to parse the git configuration, which could be cumbersome, a check like !$? -or $LASTEXITCODE -eq 128 right after the git clone command should be sufficient.
In case of error you can then proceed with cloning via SSH

Downloading zip files as the fallback would be a better way to solve this I guess, considering there might be evironment having SSH cloning disabled.

@xxthunder any thoughts on this?

[xxthunder]

@chawyehsu @aetonsi Oh yes, this is definitely a regression of #40 , sorry for that. I like your idea falling back to downloading the zips instead. This feature was introduced due to proxy access, so ssh would probably not work in such an environment anyway. I will implement a fallback to zips, so stay tuned.

[aetonsi]

yeah the zip fallback is surely simpler and more useful than cloning via SSH, i didn't think of that. nice 👍

[xxthunder]

@chawyehsu Did you have any time looking into my changes?

[xxthunder]

One question: why should anyone disable https for git? Even if we implement the fallback scoop won't work at all, wouldn't it?

scoop update --all

Updating Scoop...

fatal: transport 'https' not allowed

Update failed.

[aetonsi]

A simple reason might be to enforce the use of SSH keys, by throwing errors on any accidental use of any other transport.
Anyway since it's not some cryptic/unknown git feature, i think it should be taken into consideration, also because sometimes the user might not be administrator and might not have the rights to alter git's configuration or install software, and scoop is a nice way to still run and somewhat manage applications