Manfred, I was having the same problem. I finally worked out how to get past that problem.
I did not want to put all the git programs into the /bin programs. So the problem was how to get the the path changed in a non-login non-interactive shell (which is what gets generated to handle the request). /etc/profile and ~/.profile only get invoked from a login shell, so I couldn’t use those to set the path. .bashrc only gets invoked from a non-login interactive shell, so it did not do the trick by itself either.
What I ended up needing to do was first modify the /etc/ssh/sshd_config file to uncomment and set
PermitUserEnvironment yes
which then allows you to have a ~/.ssh/environment file which contains
BASH_ENV=~/.bashrc
so now in a non-login non-interactive shell, you can get the ~/.bashrc (or any other script you put in the BASH_ENV variable above) to execute.
In my ~/.bashrc I have
export PATH=/usr/local/git/bin:$PATH
which now got me access to the executables.
Problem 1 solved, but I’m still running into a second problem that I have not overcome yet, perhaps because the product is not ready to run as a server yet.
From my git repository on my windows machine I run
git remote add myZOS ssh://myUser@myZOS.mydomain.com/u/myUser/mygit/myProduct
git pull myZOS
and get a response of
fatal: protocol error: bad line length character: ▒▒▒
Unable to write to standard output: The pipe is being closed.
This often is related to a problem with a response of some error, so I used
ssh myUser@myZOS.mydomain.com git-receive-pack /u/myUser/mygit/myProduct
to verify. I was having a problem with the public key, Once I fixed that, I now get
fatal: protocol error: bad line length character:
followed by some junk… I haven’t gotten past that yet.