git(-with-openssh): Restore git.exe shim

[Hahihula]

The recent update of the git.json and git-with-openssh.json remove the shim for git.exe which was previously there. This update returns it back an not only git-bash.exe should be exposed in the shims

Relates to #7459

• Use conventional PR title: <manifest-name[@version]|chore>: <general summary of the pull request>
• I have read the Contributing Guide

[github-actions]

All changes look good.

Wait for review from human collaborators.

git-with-openssh

• Lint
• Description
• License
• Hashes
• Checkver
• Autoupdate
• Autoupdate Hash Extraction

git

• Lint
• Description
• License
• Hashes
• Checkver
• Autoupdate
• Autoupdate Hash Extraction

Check the full log for details.

[SorYoshino]

The official installer directly appends the cmd directory to the Path environment variable, and the useful tools contained in this directory extend well beyond git, gitk, and scalar. Rather than enumerating these utilities individually in the bin field, it is more appropriate to add the entire cmd directory to Path.

• The reason for removing cmd\git.exe has already been provided in git(-with-openssh): Improve registry srcipt & relevant logic, update checkver & autoupdate #7459, as shown above.

• Adding $dir\cmd to the Path variable does not affect the user's ability to use Git in powershell or cmd. Therefore, there is no need to re-add git.exe to the bin field.

┏[ ~]
└─> Get-Command -Name 'git.exe' -CommandType Application

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     git.exe                                            2.52.0.1   D:\Software\Scoop\Global\apps\Git\current\cmd\git.exe

┏[ ~]
└─> git --version
git version 2.52.0.windows.1

[SorYoshino]

Additionally, I removed bin\bash.exe from the bin field because the hash of bin\bash.exe is identical to that of bin\sh.exe. Furthermore, users who have WSL (Windows Subsystem for Linux) installed may experience conflicts or issues when attempting to use bin\bash.exe.

[Hahihula]

The official installer directly appends the cmd directory to the Path environment variable, and the useful tools contained in this directory extend well beyond git, gitk, and scalar. Rather than enumerating these utilities individually in the bin field, it is more appropriate to add the entire cmd directory to Path.

• The reason for removing cmd\git.exe has already been provided in git(-with-openssh): Improve registry srcipt & relevant logic, update checkver & autoupdate #7459, as shown above.
• Adding $dir\cmd to the Path variable does not affect the user's ability to use Git in powershell or cmd. Therefore, there is no need to re-add git.exe to the bin field.

┏[ ~]
└─> Get-Command -Name 'git.exe' -CommandType Application

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     git.exe                                            2.52.0.1   D:\Software\Scoop\Global\apps\Git\current\cmd\git.exe

┏[ ~]
└─> git --version
git version 2.52.0.windows.1

This is only true if there would be no existing third party integration expecting it to be there, also this means that after installing adding the shims folder to path is not enough which previously was.
So it does not affect the ability of users to use git in new user session, but they actually can not use it right away as they previously could.

[SorYoshino]

So it does not affect the ability of users to use git in new user session, but they actually can not use it right away as they previously could.

In practice, this does not prevent users from immediately using git, as can be seen from the relevant code and the examples below.

https://github.com/ScoopInstaller/Scoop/blob/b588a06e41d920d2123ec70aee682bae14935939/lib/system.ps1#L96-L120

┏[ ~]
└─> scoop list ldc
Installed apps matching 'ldc':

┏[ ~]
└─> $env:Path -match 'ldc'
False

┏[ ~]
└─> scoop install ldc
Installing 'ldc' (1.41.0) [64bit] from 'main' bucket
Loading ldc2-1.41.0-windows-x64.7z from cache.
Checking hash of ldc2-1.41.0-windows-x64.7z ... ok.
Extracting ldc2-1.41.0-windows-x64.7z ... done.
Linking D:\Software\Scoop\Local\apps\ldc\current => D:\Software\Scoop\Local\apps\ldc\1.41.0
Adding D:\Software\Scoop\Local\apps\ldc\current\bin to your path.
'ldc' (1.41.0) was installed successfully!

┏[ ~]
└─> $env:Path -match 'ldc'
True

┏[ ~]
└─> Get-Command -Name 'ldc2.exe' -CommandType Application

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     ldc2.exe                                           0.0.0.0    D:\Software\Scoop\Local\apps\ldc\current\bin\ldc2.exe

[z-Fng]

Is there a conflict if the bin\git.exe shim co-exists with cmd\git.exe in the PATH? If not, we can consider keeping both.

[SorYoshino]

Is there a conflict if the bin\git.exe shim co-exists with cmd\git.exe in the PATH?

Under normal usage, there should be no conflicts. Which git is actually used depends on the order of $shimdir and cmd in the PATH environment variable.

---

The following content is newly added:

However, do we really need to recreate the bin\git.exe shim?

I previously fell into a habitual line of thinking and did not consider shells other than PowerShell. That said, the situation where git cannot be found would generally occur only once. Repeated occurrences would only be possible if no_junction is set to true and scoop cleanup git is executed after updating Git, while continuing to use the same session without starting a new one.

The likelihood of all these conditions being met simultaneously is very low. It is also reasonable to assume that most users would not keep using the same session for an extended period without reloading environment variables. In my view, a one-time occurrence is acceptable, as this behavior is consistent with how traditional installers work.

Do we really want to introduce an approach that appears inherently contradictory in order to address an issue that is unlikely to occur?