Hello there!
I am trying to install GIT on a linux server to use it for SSH access
with msysgit. I am having trouble with the way the permissions are
set up in terms of setting the path, so that non-interactive ssh
shells can find the process. The upshot is something like this, which
is common on the web for misconfigured .bashrc or .bash_profile
or .profile situations:
C:\>git clone ssh://[EMAIL PROTECTED]/git/Project
Initialized Project/.git
Initialized empty Git repository in C:/Project/.git/
Password: (I type password here)
sh: line 1: git-upload-pack: command not found
fatal: The remote end hung up unexpectedly
A search for "git-upload-pack: command not found" leads to some common
reasons, but even after going through all those I couldn't get it to
work. I do not blame Git for this portion, because I had the same
path problem with mercurial. I'm thinking it's something with the way
the linux server was set up, like maybe there's a System-wide
PermitUserEnvironment not enabled in /etc/ssh/sshd_config? But I'm an
ssh ignoramus, so what do I know--I'm putting the sysadmin experts on
that particular case. :) I'll follow up if they crack it.
I tried to push onward, but hit a brick wall. With mercurial I was
able to work around it by explicitly naming the path to the executable
in /.hg/hgrc:
[ui]
remotecmd = /home/me/mercurial-1.0.1/hg
Git theoretically offers this option, for instance with --upload-pack
(which I assume lets you do the same kind of thing?) But it doesn't
seem that option is in Git clone, only Git pull. Plus when I try
that, I get this:
C:\>git init
Initialized empty Git repository in C:/Project/.git/
C:\>git pull ssh://[EMAIL PROTECTED]/git/Project --upload-pack /home/
me/git-1.5.6.1/git-upload-pack
Initialized Project/.git
Initialized empty Git repository in C:/Project/.git/
Password: (I type password here)
sh: line 1: C:/Program: No such file or directory
fatal: The remote end hung up unexpectedly
It looks like some sort of command line processing bug tied into
handling of spaces in command lines and filenames, which is brain-dead
in Windows (I know this for a fact). Quote marks around the path
don't help. I don't know how it is getting the idea to put C:\Program
[Files] paths into the command it runs on the remote server...
Any ideas on what's happening?
Regards,
---
http://hostilefork.com
