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

Question

Я использовал 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.

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

Answer 1

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

Answer 2

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

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

Answer 3

Опираясь на Ответ Брайана , путь загрузки пакета можно установить постоянно, выполнив следующие команды после клонирования, что устраняет необходимость в --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

Answer 4

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

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

Благодаря Полу Джонстону .

Answer 5

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

#PermitUserEnvironment no

до

PermitUserEnvironment yes

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

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

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

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

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

Answer 6

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

Answer 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

Execute:

chmod +x /usr/local/bin/ssh_session

Добавить следующее к /etc/sshd_config:

ForceCommand / usr / local / bin / ssh_session

Answer 8

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

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

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

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

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

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

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

Answer 9

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

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

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

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

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

Answer 10

Как Йохан много раз указывал на необходимый .bashrc:

ln -s .bash_profile .bashrc