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" не работает, потому что я не думаю, что есть --unpack= вариант.
Кстати, все команды git работают нормально с моего локального компьютера, это та же версия программного обеспечения (1.5.4.2), установленная на том же устройстве NFS в /usr/local/bin,
Кто-нибудь может помочь?
17 ответов
Удостовериться git-upload-pack находится на пути из оболочки без входа в систему. (На моей машине это в /usr/bin).
Чтобы увидеть, как выглядит ваш путь на удаленной машине из оболочки без регистрации, попробуйте это:
ssh you@remotemachine echo \$PATH
(Это работает в Bash, Zsh и tcsh и, возможно, в других оболочках.)
Если путь, который он возвращает, не включает в себя каталог, который имеет git-upload-pack, вам нужно исправить это, установив его в .bashrc (для Баша), .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 на последующие запросы извлечения / извлечения. Аналогичным образом, настройка 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 и некоторых других Unix по крайней мере пользовательский путь компилируется в sshd по соображениям безопасности, поэтому те из нас, кто устанавливает git как /usr/local/git/{bin,lib,...}, могут столкнуться с проблемами в качестве git исполняемые файлы не находятся в предварительно скомпилированном пути. Чтобы переопределить это, я предпочитаю изменить мой /etc/sshd_config, изменив:
#PermitUserEnvironment no
в
PermitUserEnvironment yes
и затем создайте файлы ~/.ssh/environment по мере необходимости. Мои пользователи git имеют в своем файле ~/.ssh/environment следующее:
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/git/bin
Обратите внимание, что расширение переменной не происходит, когда файл ~/.ssh/environment читается так:
PATH=$PATH:/usr/local/git/bin
не будет работать.
Решение Мэтта не работает для меня на 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
Для bash его нужно поместить в.bashrc, а не.bash_profile (.bash_profile также только для оболочек входа в систему).
Я получил эти ошибки с версией MsysGit.
Следуя всем советам, которые я мог найти здесь и в другом месте, я оказался:
установка Cygwin-версии Git
на сервере (Win XP с Cygwin SSHD) это наконец исправлено.
Я все еще использую версию клиента MsysGit
.. фактически, это единственный способ, которым он работает для меня, так как я получаю ошибки POSIX с помощью Cygwin Git pull с того же сервера sshd
Я подозреваю, что некоторая работа все еще необходима в этой части использования Git.. (SSH + легкость тянуть / толкать в Windows)
Как Йохан много раз указывал на его.bashrc, который нужен:
ln -s.bash_profile.bashrc
Это может быть так же просто, как установка git на удаленном хосте (как это было в моем случае).
sudo apt-get install git
Или эквивалент для других систем управления пакетами.
В моем случае используется Win 10 с GIT bash, и у меня нет GIT в стандартном расположении. Вместо этого у меня есть git в /app/local/bin. Я использовал команды, предоставленные @Garrett, но мне нужно изменить путь, чтобы начать с двойного /:
git config remote.origin.uploadpack //path/to/git-upload-pack
git config remote.origin.receivepack //path/to/git-receive-pack
В противном случае GIT добавит ваш путь к Windows GIT впереди.
Вы должны добавить
export PATH=/opt/git/bin:$PATH
перед этой строкой в .bashrc:
# If not running interactively, don't do anything
[ -z "$PS1" ] && return
В противном случае все операторы экспорта не будут выполнены ( см. Здесь).
Добавьте местоположение вашего git-upload-pack в файл.bashrc удаленного пользователя git.
Для меня это похоже на ошибку в настройке.
Я использую сервер Windows и просто настраиваю Git с настройками по умолчанию. Ни в каких инструкциях не было упоминания о «git-upload-pack». Я нашел исполняемый файл в папке «C:\Programs\Git\mingw64\bin» и добавил его в переменные среды Windows.
Если вы используете GitHub Enterprise , убедитесь, что репозиторий
public, нет
internal. Могут быть и другие способы решить эту проблему для внутреннего репо, но это был самый быстрый способ решить проблему, не привлекая больше времени и людей.
Для zsh вы должны поместить его в этот файл: ~/.zshenv
Например, в OS X с использованием пакета git-core от MacPorts:
$ echo 'export PATH = / opt / local / sbin: / opt / local / bin: $ PATH'> ~ /.zshenv
У меня были проблемы с подключением к репозиторию Gitolite с использованием SSH из Windows, и оказалось, что моя проблема была PLINK! Он все время спрашивал у меня пароль, но ssh gitolite@[host] вернул бы список репо в порядке.
Проверьте переменную среды: GIT_SSH. Если он установлен на Plink, попробуйте его без какого-либо значения ("set GIT_SSH=") и посмотрите, работает ли это.