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

170

Я использовал 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)команду works (и докажет, что $PATHсодержит путь к «git-upload-pack» согласно решению RTFM), но это действительно раздражает, плюс «git push» не работает, потому что я не думаю, что есть --unpack=вариант.

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

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

Крис Хуан-Ливер
источник

Ответы:

169

Убедитесь, что 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.

Мэтт Кертис
источник
2
Путь был верным, если я запускаю команду на своем компьютере, но неверным, если я запускаю его наоборот. (с удаленного компьютера обратно на мой) Редактирование моего локального .bashrc исправило это. Спасибо
Крис Хуан-Ливер
6
Работал над OSX Leopard
Ноа Кэмпбелл
1
В моем случае команда не была найдена, потому что git был установлен через MacPorts, который вставляет ее /opt/local/bin. Добавление этого в мой .bashrcvia PATH=$PATH:/new/path/hereработал для меня.
Бен Шейрман
1
@ranReloaded Предполагается, что обратный слеш экранирует знак доллара и предотвращает расширение $ PATH на локальном компьютере, а вместо этого передает «echo $ PATH» буквально на удаленный компьютер. Это может зависеть от того, какую оболочку вы используете; у меня это работает в zsh и bash. Вы можете получить правильный результат, используя одинарные кавычки, например, "ssh you @ remotemachine 'echo $ PATH'" - попробуйте. В противном случае, какую оболочку вы используете? Может быть, кто-то еще использует эту оболочку и может дать вам обходной путь.
Мэтт Кертис
3
@ranReloaded: Когда вы говорите «путь git не печатается», вы имеете в виду, что ssh показывает много вещей, но не путь, по которому идет git? Если это так, то у вас точно такая же проблема, как и у OP, а использование символической ссылки - просто бандит. "ssh .. echo \$PATH" Команда покажет вам путь на удаленную машине, которая может отличаться от вашего входа в пути, но это важная вещь , чтобы получить право сделать его работу, и вы можете сделать это, установив переменную PATH , чтобы включить мерзавец в .bashrcна удаленная машина. Согласно man-странице, .profile/ .bash_profileчитаются только для интерактивных входов в систему.
Мэтт Кертис
66

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

git clone -u /home/you/bin/git-upload-pack you@machine:code
Брайан Хокинс
источник
2
Спасибо за это. Я действительно не хотел менять файл ~ / .bashrc.
Луис
2
Просто обратите внимание: здесь приведены инструкции о том, как сделать .bashrc полученным из сессий ssh.
sp3ctum
58

Основываясь на ответе Брайана , путь загрузки пакета можно установить постоянно, выполнив следующие команды после клонирования, что устраняет необходимость --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
Garrett
источник
Спасибо за упоминание --receive-packопции git-push!
Аксель
1
Спасибо за упоминание параметров конфигурации, это полезный штрих из пространства пользователя.
Арон Ахмадиа
Я попробовал ваше предложение, также добавил «which git-receive-pack» к пути в .bashrc, но каким-то образом git push все еще не работает для меня, хотя загрузка репо работает нормально. Есть идеи, почему это могло произойти?
coredump
@coredump, установка «remote.origin.receivepack» должна устранить необходимость изменять PATH в вашем .bashrc. Попробуйте git push --receive-pack /full/path/to/git-receive-packсами, настраивайте до тех пор, пока это не будет успешно, затем измените .git / config (или запустите "git config"), чтобы окончательно установить путь к полученному пакету.
Гаррет
Спасибо всем за ваши ответы! В моем случае сервер выборки и push-сервер были разными, и у сервера выборки не было разрешений на запись. когда я использую git push <push-server> <branch>, все работает нормально.
coredump
30

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

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

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

Энди
источник
исправлено для меня, а также. Спасибо!
Джон Баллинджер
12

В 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

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

Том
источник
Это похоже на идеальный совет, но он не работает здесь для 10.6.6. ssh user @ host echo \ $ PATH по-прежнему показывает жестко закодированный путь сборки. Добавлен .ssh / environment с нерасширяемым обязательным путем. Изменено / etc / sshd_config PermitUserEnvironment да. без кости Какие-либо предложения? Спасибо.
Папа
Также попытался установить BASH_ENV = '~ / .nibashrc' на клиентском компьютере и создать в нем файл с расширенным путем. Также нет кости.
Папа
Хорошо. поэтому путь в .bashrc на машине, к которой вы подключаетесь, работал для меня.
Папа
спасибо за совет о том, что расширение переменных не работает для .ssh / environment
Денис
Upvote для объяснения того, что расширение var работает.
XMAN
7

Решение Мэтта не работает для меня на 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

Skeletron
источник
Интересно, что это не сработало для вас. Вы не против рассказать, что было написано PATH на удаленной машине, когда вы запустили «ssh you @ remote \ $ PATH»?
Мэтт Кертис
7

Для bash его нужно поместить в .bashrc, а не .bash_profile (.bash_profile также только для оболочек входа в систему).

Эндрю Гримм
источник
5

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

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

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

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

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

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

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

Рик Токио
источник
1

Как Йохан много раз указывал на его .bashrc, который нужен:

ln -s .bash_profile .bashrc

Стефан Лундстрем
источник
1

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

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

перед этой строкой в ​​.bashrc:

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

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

Деннис
источник
1

Мой случай на 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 добавит ваш путь к GIT Windows впереди.

felixc
источник
0

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

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

$ echo 'export PATH = / opt / local / sbin: / opt / local / bin: $ PATH'> ~ / .zshenv

miknight
источник
0

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

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

RAVolt
источник
0

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

Yeison
источник
0

Это может быть так же просто, как установка git на удаленном хосте (как это было в моем случае).

sudo apt-get install git

Или эквивалент для других систем управления пакетами.

truefusion
источник