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

Ответ 1

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

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

ssh [email protected] 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

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

git clone -u /home/you/bin/git-upload-pack [email protected]:code

Ответ 3

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

Ответ 4

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

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

Благодаря Paul Johnston.

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

Краткая версия ссылки Paul:

Создан /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

Ответ 8

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

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

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

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

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

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

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

Ответ 9

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

ln -s.bash_profile.bashrc

Ответ 10

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

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

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

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

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

Ответ 11

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

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

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

Ответ 12

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

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

Ответ 13

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

Ответ 14

Мой случай на 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 впереди.