Release 2.40.0.windows.1 missing git-receive-pack and git-send-pack

[jplejacq-quoininc-com]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

git version 2.39.2.windows.1
cpu: x86_64
built from commit: a82fa99b36ddfd643e61ed45e52abe314687df67
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

Microsoft Windows [Version 10.0.22000.1696]

• What options did you set as part of the installation? Or did you choose the
  defaults?

> type "C:\Program Files\Git\etc\install-options.txt"
Editor Option: VIM
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

Nothing. Vanilla install.

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

PowerShell

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

From another machine, if we do either push or pull, we will see the following errors.

git push
jplejacq@qipf1y4mle.quoininc.com's password: 
git-receive-pack : The term 'git-receive-pack' is not recognized as the name of a cmdlet, 
function, script file, or operable program. Check the spelling of the name, or if a path was 
included, verify that the path is correct and try again.
At line:1 char:1
+ git-receive-pack '/Users/jplejacq/workspace/qi-credentials-doc'
+ ~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (git-receive-pack:String) [], CommandNotFoundExcept 
   ion
    + FullyQualifiedErrorId : CommandNotFoundException
 
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

If I rollback to version 2.39.2, the problem disappears. A file system search shows that the required executables git-send-pack.exe and git-receive-pack.exe are no longer distributed by 2.40.0. They were previously located under C:\Program Files\Git\mingw64\libexec\git-core\

[dscho]

A file system search shows that the required executables git-send-pack.exe and git-receive-pack.exe are no longer distributed by 2.40.0. They were previously located under C:\Program Files\Git\mingw64\libexec\git-core\

That is indeed the case, and is covered by the ReleaseNotes:

• In the olden Git days, there were "dashed" Git commands (e.g. git-commit instead of git commit). These haven't been supported for interactive use in a really, really long time. But they still worked in Git aliases and hooks ("scripts"). Since Git v1.5.4 (released on February 2nd, 2008), it was discouraged/deprecated to use dashed Git commands even in scripts. As of this version, Git for Windows no longer supports these dashed commands.

Now, git-receive-pack.exe is there, just not in libexec:

$ find /mingw64 -name git-receive-pack.exe
/mingw64/bin/git-receive-pack.exe

The really curious thing is: why does your setup require these long-deprecated dashed forms, when I can push branches left and right without running into these troubles?

Even more curiouser: why is git-receive-pack a problem, that's on the server side when you push. Are you saying that you are pushing to a Windows machine? If so, that's hardly an uninteresting thing about your environment, I'd say. The obvious and important follow-up question would be why the git-receive-pack.exe in C:\Program Files\Git\mingw64\bin is not found.

[jplejacq-quoininc-com]

Thanks for the quick response.

The previous version (2.39.2) had these:

C:\Program Files\Git\mingw64\libexec\git-core\git-send-pack.exe
C:\Program Files\Git\mingw64\libexec\git-core\git-receive-pack.exe
C:\Program Files\Git\mingw64\bin\git-receive-pack.exe

The new version (2.40.0) has these:
C:\Program Files\Git\mingw64\bin\git-receive-pack.exe

Several other "dash" programs are also missing.

I was able to resolve the error by including the following in the system PATH. Only the second is added by the installer. It seems both are necessary.

%PROGRAMFILES%\Git\mingw64\bin
%PROGRAMFILES%\Git\cmd

Our use case is the following. We require a Windows machine with VPN software that is unavailable on Linux solely to access a git repository. We cloned a bare repository on the windows machine. On our Linux (Debian Bullseye) workstations where we do all our development we clone from the Windows repository and then push/pull as development requires. Debian currently has version 2.39.2 of git. It's the Debian git that seem to be requiring the "dash" executables.

We've used this type of configuration for many years now. It's a wonderful example of how git allows workarounds for environmental constraints that are out of our control.

The ticket can be closed though you might consider a change to the installer or documentation about modifying the PATH.

[dscho]

Several other "dash" programs are also missing.

As the release notes state: This is intentional.

I was able to resolve the error by including the following in the system PATH. Only the second is added by the installer. It seems both are necessary.

%PROGRAMFILES%\Git\mingw64\bin
%PROGRAMFILES%\Git\cmd

The need for this is definitely unintentional. You could achieve the workaround by choosing the Path option in the installer to expose all Unix-y tools to the command-line, but that should definitely not be necessary.

I wonder, however, how this worked before.

Is it maybe because the git-receive-pack.exe file was also in libexec/git-core? If so, I am curious why this code does not append /mingw64/bin to the PATH.

Could you tell us more about the way you push to/fetch from your Windows machine? Is it an SSH server? Or an HTTP server?

[jplejacq-quoininc-com]

As mentioned, we do all our development on Linux (Debian Bullseye) workstations, not servers. We are using the standard Debian git and openssh-client packages as shown below. We interact with the Windows git repository using the ssh protocol with password authentication. We will change the authentication to openssh certificates shortly now that we have the basics working.

$ apt-cache policy git
git:
  Installed: 1:2.39.2-1~bpo11+1
$ apt-cache policy openssh-client
openssh-client:
  Installed: 1:8.4p1-5+deb11u1

On the Windows side we using the standard Windows winget utility to install and manage git. This does not give us the option to configure interactively. We use the standard Windows openssh server service. We have had no issues between the Linux and Windows ssh implementations. We are running a fully up to date Windows 11 Pro.

$ winget list

Name                             Id                                Version               Available Source
----------------------------------------------------------------------------------------------------------
Git                              Git.Git                           2.40.0                          winget

[dscho]

We use the standard Windows openssh server service.

This is the part that is quite unclear to me. Could you elaborate?

[rimrul]

We use the standard Windows openssh server service.

This is the part that is quite unclear to me. Could you elaborate?

That honestly seems to explain most of the issue. Their server is a windows 11 machine that runs the sshd from the system OpenSSH (Via the optional Windows feature OpenSSH server). That uses powershell as a login shell by default, which explains the weird error message

is not recognized as the name of a cmdlet, function, script file, or operable program.

They manually added C:\ Program Files\Git\mingw64\libexec\git-core\ and C:\ Program Files\Git\mingw64\libexec\bin to $env:PATH, which is how their powershell previously found git-receive-pack.exe. Our /usr/bin/sshd would find the files in /mingw64/bin, but the system sshd knows nothing about that.

[dscho]

Ah, that explains it! I guess the only way we could support that better would be to copy the Git wrapper into cmd\git-receive-pack.exe (and cmd\git-send-pack.exe?). @rimrul what do you think?

[rimrul]

That seems reasonable.

[dscho]

I honestly don't find the time to work on this. @jplejacq-quoininc-com do you think you can? Maybe it would be as easy as copying C:\Program Files\Git\cmd\git.exe to C:\Program Files\Git\cmd\git-receive-pack.exe and then adding that folder to PATH instead of C:\Program Files\Git\mingw64\libexec\bin.

[driver1998]

Maybe it would be as easy as copying C:\Program Files\Git\cmd\git.exe to C:\Program Files\Git\cmd\git-receive-pack.exe and then adding that folder to PATH instead of C:\Program Files\Git\mingw64\libexec\bin.

I tried your suggestion, but after I did this, running git-receive-pack.exe in Powershell shows up the git commandline help (the same as git.exe)

PS C:\> git --version
git version 2.41.0.windows.1
PS C:\> where.exe git
C:\Program Files\Git\cmd\git.exe
PS C:\> where.exe git-receive-pack
C:\Program Files\Git\cmd\git-receive-pack.exe
PS C:\> git-receive-pack
usage: git [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>]
           [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
           [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--bare]
           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
           [--config-env=<name>=<envvar>] <command> [<args>]

These are common Git commands used in various situations:
[SNIP]
PS C:\> git
usage: git [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>]
           [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
           [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--bare]
           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
           [--config-env=<name>=<envvar>] <command> [<args>]

These are common Git commands used in various situations:
[SNIP]
PS C:\> & '.\Program Files\Git\mingw64\bin\git-receive-pack.exe'
fatal: you must specify a directory

usage: git receive-pack <git-dir>

    -q, --quiet           quiet
    --advertise-refs ...  alias of --http-backend-info-refs

PS C:\>

[dscho]

@driver1998 maybe you are motivated to work on a fix? To get you started:

1. install Git for Windows' SDK,
2. sdk cd mingw-w64-git,
3. initialize the clone and build the package via sdk build
4. edit src/git-wrapper.c (it might need a clone of this clause to handle git-receive-pack.exe and git-send-pack.exe
5. build it via make -C src/git -f ../mingw-w64-git.mak git-wrapper.exe and copy git-wrapper.exe to the cmd folder under the new name git-receive-pack.exe
6. to find out why it is not working (if it is not working), add MessageBoxW() statements to see where the code flows and what values control the flow, edit and repeat
7. open a PR?

[driver1998]

Yeah I did try to compile the wrapper and find out what it is doing. It goes to the "invoke builtin" branch.
I didn't touch it since am not sure if it is meant to do that. (git receive-pack will work in git bash but it seems to get in a dead loop when I let the wrapper to call git receive-pack).
But yeah I will try to hack it again.

[dscho]

Yeah I did try to compile the wrapper and find out what it is doing. It goes to the "invoke builtin" branch.

The invoke built-in branch should expect a git.exe to be in the same directory, and to call it. Does that not happen? What is the command-line that is invoked?

BTW if MessageBoxW()-style debugging is too tedious, it might be better to add code to append to a file, something like:

{
  FILE *fl = fopen("a1.log", "a");
  fprintf(fl, "Here is some wide-character string: '%ls'\n", wcommandline);
  fclose(fl);
}

[driver1998]

At the CreateProcess call:
exep: C:\Program Files\Git\cmd\git.exe
cmd: git-receive-pack

But it still gives me git.exe messages.

[driver1998]

I just noticed if I call cmd/git.exe, exep is C:\Program Files\Git\mingw64\bin\git.exe instead of C:\Program Files\Git\cmd\git.exe, so I changed it in the Call a builtin branch as well, that seems to work just fine.