views:

14282

answers:

11

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?

+54  A: 

Make sure git-upload-pack is on the path from a non-login shell. (On my machine it's in /usr/bin).

To see what your path looks like on the remote machine from a non-login shell, try this:

ssh you@remotemachine echo \$PATH

(That works in Bash, Zsh, and tcsh, and probably other shells too.)

If the path it gives back doesn't include the directory that has git-upload-pack, you need to fix it by setting it from .bashrc (for Bash), .zshenv (for Zsh), .cshrc (for tcsh) or equivalent for your shell.

Matt Curtis
The path was correct if I run the command on my machine, but wrong if I run it the other way around. (from the remote machine back to mine) Editing my local .bashrc fixed it. Thanks
Chris Huang-Leaver
Against Chris's comments, I found that when Matt's command reported the wrong path, I logged in with "ssh you@remotemachine" and changed the .bashrc there; that fixed the problem.Changing the "local" .bashrc makes no difference that I can see.
Dan Fabulich
I had ssh'd into a remote machine trying to pull from local system, which is why my .bashrc was the one to change. It's the same issue as you but reversed.
Chris Huang-Leaver
Worked on OSX Leopard
Noah Campbell
I had an additional problem; when I ssh'd into the remote machine and executed git-upload-pack, it found it find, but not when I was cloning. (ie: the PATH was different between the direct login and the remote execution). Setting the path in .bashrc, as described here, fixed the problem.
Craig Walker
Good to hear Craig. The way you describe it, I think it's actually the same problem the OP had.
Matt Curtis
David Zaslavsky
On OS X it seems to use `.profile` by default(?), `ln -s .profile .bashrc` fix this for me..
dbr
+2  A: 

I had the same problem with a Windows client connecting to an old FedoraCore 4 system. The solution pointed me in the right direction but changing .bash_profile etc didn't help as they aren't being ran by default by ssh.

The solution was here: link text

Paul Hargreaves
+4  A: 

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

Skeletron
Interesting to hear it didn't work for you. Do you mind telling what it said PATH on the remote machine was, when you ran "ssh you@remote \$PATH"?
Matt Curtis
+10  A: 

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.

Andy
worked for me on OSX who installed git via macports
ozone
+4  A: 

For bash, it needs to be put into .bashrc not .bash_profile (.bach_profile is also only for login shells).

+1  A: 

There was a bug in relatively recent versions of git (1.5.x, not sure if it's fixed in 1.6.x yet), where when they obsoleted the 'dashed form' of the git commands, they neglected to test the operation of sync'ing via ssh.

As a result, you must symbolic link the appropriate binaries until the code is updated, or submit a patch.

Arafangion
A: 

Like Johan pointed out many times its .bashrc that's needed:

ln -s .bash_profile .bashrc

Stefan Lundström
+2  A: 

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)

Ric Tokyo
A: 

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

miknight
+13  A: 

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
Brian Hawkins
Thanks for that. I really didn't want to change the ~/.bashrc file.
Luis
Very helpful, thanks.
ayaz
+2  A: 

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.

tom