I have been using git to keep two copies of my project in sync, one is my local box, the other the test server. This is an issue which occurs when I log onto our remote development server using ssh;
git clone [email protected]:/home/chris/myproject
Initialized empty Git repository in /tmp/myproject/.git/
Password:
bash: git-upload-pack: command not found
fatal: The remote end hung up unexpectedly
fetch-pack from '[email protected]:/home/chris/myproject' failed.
(the file-names have been changed to protect the guilty... !)
Both boxes run Solaris 10 AMD. I have done some digging, if I add --upload-pack=$(which git-upload-pack)
the command works, (and proves that $PATH
contains the path to 'git-upload-pack' as per the RTFM solution) but this is really annoying, plus 'git push' doesn't work, because I don't think there is a --unpack=
option.
Incidentally, all the git commands work fine from my local box, it is the same version of the software (1.5.4.2), installed on the same NFS mount at /usr/local/bin
.
Can anybody help?
This question is related to
git
version-control
unix
ssh
Like Johan pointed out many times its .bashrc that's needed:
ln -s .bash_profile .bashrc
For zsh you need to put it in this file: ~/.zshenv
For example, on OS X using the git-core package from MacPorts:
$ echo 'export PATH=/opt/local/sbin:/opt/local/bin:$PATH' > ~/.zshenv
My case is on Win 10 with GIT bash and I don't have a GIT under standard location. Instead I have git under /app/local/bin. I used the commands provided by @Garrett but need to change the path to start with double /:
git config remote.origin.uploadpack //path/to/git-upload-pack
git config remote.origin.receivepack //path/to/git-receive-pack
Otherwise the GIT will add your Windows GIT path in front.
Matt's solution didn't work for me on OS X, but Paul's did.
The short version from Paul's link is:
Created /usr/local/bin/ssh_session
with the following text:
#!/bin/bash
export SSH_SESSION=1
if [ -z "$SSH_ORIGINAL_COMMAND" ] ; then
export SSH_LOGIN=1
exec login -fp "$USER"
else
export SSH_LOGIN=
[ -r /etc/profile ] && source /etc/profile
[ -r ~/.profile ] && source ~/.profile
eval exec "$SSH_ORIGINAL_COMMAND"
fi
Execute:
chmod +x /usr/local/bin/ssh_session
Add the following to /etc/sshd_config
:
ForceCommand /usr/local/bin/ssh_session
For bash, it needs to be put into .bashrc not .bash_profile (.bash_profile is also only for login shells).
You can also use the "-u" option to specify the path. I find this helpful on machines where my .bashrc doesn't get sourced in non-interactive sessions. For example,
git clone -u /home/you/bin/git-upload-pack you@machine:code
Building on Brian's answer, the upload-pack path can be set permanently by running the following commands after cloning, which eliminates the need for --upload-pack
on subsequent pull/fetch requests. Similarly, setting receive-pack eliminates the need for --receive-pack
on push requests.
git config remote.origin.uploadpack /path/to/git-upload-pack
git config remote.origin.receivepack /path/to/git-receive-pack
These two commands are equivalent to adding the following lines to a repo's .git/config
.
[remote "origin"]
uploadpack = /path/to/git-upload-pack
receivepack = /path/to/git-receive-pack
Frequent users of clone -u
may be interested in the following aliases. myclone should be self-explanatory. myfetch/mypull/mypush can be used on repos whose config hasn't been modified as described above by replacing git push
with git mypush
, and so on.
[alias]
myclone = clone --upload-pack /path/to/git-upload-pack
myfetch = fetch --upload-pack /path/to/git-upload-pack
mypull = pull --upload-pack /path/to/git-upload-pack
mypush = push --receive-pack /path/to/git-receive-pack
I found and used (successfully) this fix:
# Fix it with symlinks in /usr/bin
$ cd /usr/bin/
$ sudo ln -s /[path/to/git]/bin/git* .
Thanks to Paul Johnston.
I have been having issues connecting to a Gitolite repo using SSH from Windows and it turned out that my problem was PLINK! It kept asking me for a password, but the ssh gitolite@[host] would return the repo list fine.
Check your environment variable: GIT_SSH. If it is set to Plink, then try it without any value ("set GIT_SSH=") and see if that works.
Mac OS X and some other Unixes at least have the user path compiled into sshd for security reasons so those of us that install git as /usr/local/git/{bin,lib,...} can run into trouble as the git executables are not in the precompiled path. To override this I prefer to edit my /etc/sshd_config changing:
#PermitUserEnvironment no
to
PermitUserEnvironment yes
and then create ~/.ssh/environment files as needed. My git users have the following in their ~/.ssh/environment file:
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/git/bin
Note variable expansion does not occur when the ~/.ssh/environment file is read so:
PATH=$PATH:/usr/local/git/bin
will not work.
I got these errors with the MsysGit version.
After following all advice I could find here and elsewhere, I ended up:
installing the Cygwin version of Git
on the server (Win XP with Cygwin SSHD), this finally fixed it.
I still use the MsysGit version client side
..in fact, its the only way it works for me, since I get POSIX errors with the Cygwin Git pull from that same sshd server
I suspect some work is still needed this side of Git use.. (ssh+ease of pull/push in Windows)
For zsh you need to put it in this file: ~/.zshenv
For example, on OS X using the git-core package from MacPorts:
$ echo 'export PATH=/opt/local/sbin:/opt/local/bin:$PATH' > ~/.zshenv
You must add the
export PATH=/opt/git/bin:$PATH
before this line in the .bashrc:
# If not running interactively, don't do anything
[ -z "$PS1" ] && return
Otherwise all export statements will not be executed (see here).
Building on Brian's answer, the upload-pack path can be set permanently by running the following commands after cloning, which eliminates the need for --upload-pack
on subsequent pull/fetch requests. Similarly, setting receive-pack eliminates the need for --receive-pack
on push requests.
git config remote.origin.uploadpack /path/to/git-upload-pack
git config remote.origin.receivepack /path/to/git-receive-pack
These two commands are equivalent to adding the following lines to a repo's .git/config
.
[remote "origin"]
uploadpack = /path/to/git-upload-pack
receivepack = /path/to/git-receive-pack
Frequent users of clone -u
may be interested in the following aliases. myclone should be self-explanatory. myfetch/mypull/mypush can be used on repos whose config hasn't been modified as described above by replacing git push
with git mypush
, and so on.
[alias]
myclone = clone --upload-pack /path/to/git-upload-pack
myfetch = fetch --upload-pack /path/to/git-upload-pack
mypull = pull --upload-pack /path/to/git-upload-pack
mypush = push --receive-pack /path/to/git-receive-pack
It may be as simple as installing git on the remote host (like it was in my case).
sudo apt-get install git
Or equivalent for other package management systems.
Mac OS X and some other Unixes at least have the user path compiled into sshd for security reasons so those of us that install git as /usr/local/git/{bin,lib,...} can run into trouble as the git executables are not in the precompiled path. To override this I prefer to edit my /etc/sshd_config changing:
#PermitUserEnvironment no
to
PermitUserEnvironment yes
and then create ~/.ssh/environment files as needed. My git users have the following in their ~/.ssh/environment file:
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/git/bin
Note variable expansion does not occur when the ~/.ssh/environment file is read so:
PATH=$PATH:/usr/local/git/bin
will not work.
For bash, it needs to be put into .bashrc not .bash_profile (.bash_profile is also only for login shells).
Matt's solution didn't work for me on OS X, but Paul's did.
The short version from Paul's link is:
Created /usr/local/bin/ssh_session
with the following text:
#!/bin/bash
export SSH_SESSION=1
if [ -z "$SSH_ORIGINAL_COMMAND" ] ; then
export SSH_LOGIN=1
exec login -fp "$USER"
else
export SSH_LOGIN=
[ -r /etc/profile ] && source /etc/profile
[ -r ~/.profile ] && source ~/.profile
eval exec "$SSH_ORIGINAL_COMMAND"
fi
Execute:
chmod +x /usr/local/bin/ssh_session
Add the following to /etc/sshd_config
:
ForceCommand /usr/local/bin/ssh_session
My case is on Win 10 with GIT bash and I don't have a GIT under standard location. Instead I have git under /app/local/bin. I used the commands provided by @Garrett but need to change the path to start with double /:
git config remote.origin.uploadpack //path/to/git-upload-pack
git config remote.origin.receivepack //path/to/git-receive-pack
Otherwise the GIT will add your Windows GIT path in front.
I got these errors with the MsysGit version.
After following all advice I could find here and elsewhere, I ended up:
installing the Cygwin version of Git
on the server (Win XP with Cygwin SSHD), this finally fixed it.
I still use the MsysGit version client side
..in fact, its the only way it works for me, since I get POSIX errors with the Cygwin Git pull from that same sshd server
I suspect some work is still needed this side of Git use.. (ssh+ease of pull/push in Windows)
You must add the
export PATH=/opt/git/bin:$PATH
before this line in the .bashrc:
# If not running interactively, don't do anything
[ -z "$PS1" ] && return
Otherwise all export statements will not be executed (see here).
Matt's solution didn't work for me on OS X, but Paul's did.
The short version from Paul's link is:
Created /usr/local/bin/ssh_session
with the following text:
#!/bin/bash
export SSH_SESSION=1
if [ -z "$SSH_ORIGINAL_COMMAND" ] ; then
export SSH_LOGIN=1
exec login -fp "$USER"
else
export SSH_LOGIN=
[ -r /etc/profile ] && source /etc/profile
[ -r ~/.profile ] && source ~/.profile
eval exec "$SSH_ORIGINAL_COMMAND"
fi
Execute:
chmod +x /usr/local/bin/ssh_session
Add the following to /etc/sshd_config
:
ForceCommand /usr/local/bin/ssh_session
I found and used (successfully) this fix:
# Fix it with symlinks in /usr/bin
$ cd /usr/bin/
$ sudo ln -s /[path/to/git]/bin/git* .
Thanks to Paul Johnston.
Add the location of your git-upload-pack
to the remote git user's .bashrc file.
You can also use the "-u" option to specify the path. I find this helpful on machines where my .bashrc doesn't get sourced in non-interactive sessions. For example,
git clone -u /home/you/bin/git-upload-pack you@machine:code
Add the location of your git-upload-pack
to the remote git user's .bashrc file.
It may be as simple as installing git on the remote host (like it was in my case).
sudo apt-get install git
Or equivalent for other package management systems.
Like Johan pointed out many times its .bashrc that's needed:
ln -s .bash_profile .bashrc
I have been having issues connecting to a Gitolite repo using SSH from Windows and it turned out that my problem was PLINK! It kept asking me for a password, but the ssh gitolite@[host] would return the repo list fine.
Check your environment variable: GIT_SSH. If it is set to Plink, then try it without any value ("set GIT_SSH=") and see if that works.
Matt's solution didn't work for me on OS X, but Paul's did.
The short version from Paul's link is:
Created /usr/local/bin/ssh_session
with the following text:
#!/bin/bash
export SSH_SESSION=1
if [ -z "$SSH_ORIGINAL_COMMAND" ] ; then
export SSH_LOGIN=1
exec login -fp "$USER"
else
export SSH_LOGIN=
[ -r /etc/profile ] && source /etc/profile
[ -r ~/.profile ] && source ~/.profile
eval exec "$SSH_ORIGINAL_COMMAND"
fi
Execute:
chmod +x /usr/local/bin/ssh_session
Add the following to /etc/sshd_config
:
ForceCommand /usr/local/bin/ssh_session
Source: Stackoverflow.com