git-upload-pack: команда не найдена при клонировании удаленного репозитория Git

я использую git для синхронизации двух копий моего проекта, одна из которых-мой локальный ящик, а другая-тестовый сервер. Это проблема, которая возникает при входе на наш удаленный сервер разработки с помощью ssh;

git clone me@me.mydevbox.com:/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 'me@me.mydevbox.com:/home/chris/myproject' failed.

(имена файлов были изменены, чтобы защитить виновных... !)

обе коробки работают под управлением Solaris 10 AMD. Я немного покопался, если добавить --upload-pack=$(which git-upload-pack) команда работает, (и доказывает, что $PATH содержит путь к "Git-upload-pack" в соответствии с RTFM решение), но это действительно раздражает, плюс "git push" не работает, потому что я не думаю, что есть .

кстати, все команды git отлично работают из моего локального окна, это та же версия программного обеспечения (1.5.4.2), установленная на том же монтировании NFS в /usr/local/bin.

может кто-нибудь помочь?

13 ответов


убедится git-upload-pack на пути от входа раковина. (На моей машине это в /usr/bin).

чтобы увидеть, как выглядит ваш путь на удаленной машине из оболочки без входа в систему, попробуйте следующее:

ssh you@remotemachine echo $PATH

(это работает в Bash, Zsh и tcsh, и, вероятно, других оболочках тоже.)

если путь дает обратно не включает каталог git-upload-pack, вам нужно исправить это, установив его в .bashrc (для Bash), .zshenv (для Zsh), .cshrc (для tcsh) или эквивалент для вашей оболочки.

вам нужно будет сделать это изменение на удаленной машине.

если вы не уверены, какой путь вам нужно добавить к удаленному PATH, вы можете найти его с помощью этой команды (для этого нужно запустить на удаленной машине):

which git-upload-pack

на моей машине, которая печатает /usr/bin/git-upload-pack. Так что в данном случае /usr/bin путь, который вам нужно убедиться, находится в вашей удаленной оболочке без входа PATH.


вы также можете использовать опцию "-U", чтобы указать путь. Я нахожу это полезным на машинах, где мой .bashrc не получает источников в неинтерактивных сеансах. Например,

git clone -u /home/you/bin/git-upload-pack you@machine:code

дом на Брайан, путь upload-pack можно установить постоянно, выполнив следующие команды после клонирования, что исключает необходимость --upload-pack при последующих запросах pull/fetch. Аналогично, установка receive-pack устраняет необходимость в --receive-pack по push-запросам.

git config remote.origin.uploadpack /path/to/git-upload-pack
git config remote.origin.receivepack /path/to/git-receive-pack

эти две команды эквивалентны добавлению следующих строк в репо .git/config.

[remote "origin"]
    uploadpack = /path/to/git-upload-pack
    receivepack = /path/to/git-receive-pack

частые пользователи clone -u может быть заинтересован в следующие псевдонимы. myclone должен быть понятным. myfetch/mypull / mypush можно использовать в репозиториях, конфигурация которых не была изменена, как описано выше, заменив git push С git mypush и так далее.

[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

Я нашел и использовал (успешно) это исправить:

# Fix it with symlinks in /usr/bin
$ cd /usr/bin/
$ sudo ln -s /[path/to/git]/bin/git* .

спасибо Пол Джонстон.


Mac OS X и некоторые другие Униксы, по крайней мере,имеют путь пользователя, скомпилированный в sshd по соображениям безопасности, поэтому те из нас, кто устанавливает git как /usr/local/git/{bin, lib,...} может возникнуть проблема, поскольку исполняемые файлы git не находятся в предварительно скомпилированном пути. Чтобы переопределить это, я предпочитаю редактировать изменение /etc/sshd_config:

#PermitUserEnvironment no

до

PermitUserEnvironment yes

и затем создать ~/.файлы ssh / environment по мере необходимости. Мои пользователи git имеют следующее в своем~/.СШ/среды файл:

PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/git/bin

Примечание расширение переменной не происходит, когда ~/.файл ssh / environment читается так:

PATH=$PATH:/usr/local/git/bin

не будет работать.


для bash, его нужно положить в .bashrc и не .файл (.bash_profile также предназначен только для оболочек входа).


решение Мэтта не сработало для меня на OS X, но Пол сделал это.

короткая версия из ссылки Павла:

создано /usr/local/bin/ssh_session со следующим текстом:

#!/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

выполнить:

chmod +x /usr/local/bin/ssh_session

добавить /etc/sshd_config:

ForceCommand/usr/local/bin / ssh_session


Я получил эти ошибки с версией MsysGit.

после всех советов, которые я мог найти здесь и в другом месте, я закончил:

установка Cygwin версии Git

на сервере (Win XP с Cygwin SSHD) это, наконец, исправило его.

Я все еще использую клиентскую сторону версии MsysGit

..на самом деле, это единственный способ его работы для меня, так как я получаю ошибки POSIX с Cygwin Git вытащить из что же сервер sshd

Я подозреваю, что некоторая работа все еще нужна этой стороне использования Git.. (ssh + простота pull / push в Windows)


как Йохан указал много раз его .bashrc что нужно:

ln-s .файл .bashrc и


вы должны добавить

export PATH=/opt/git/bin:$PATH

перед этой строке .bashrc следующее:

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

в противном случае все операторы экспорта не будут выполняться (посмотреть здесь).


для zsh вам нужно поместить его в этот файл:~/.zshenv

например, в OS X с помощью пакета git-core от MacPorts:

$ Эхо '=/опт/местные/sbin:/опт/местные/Бен: в$Path' > ~/.zshenv

У меня были проблемы с подключением к репозиторию Gitolite с использованием SSH из Windows, и оказалось, что моя проблема была PLINK! Он продолжал спрашивать меня о пароле, но ssh gitolite@[host] вернет список РЕПО в порядке.

Проверьте переменную среды: GIT_SSH. Если он установлен в Plink, попробуйте его без какого-либо значения ("set GIT_SSH=") и посмотрите, работает ли это.


добавить местоположение git-upload-pack к удаленному пользователю git .файл bashrc.