git-upload-pack: comando não encontrado, ao clonar repositório Git remoto

Eu tenho usado o git para manter duas cópias do meu projeto sincronizadas, uma é a minha caixa local e a outra o servidor de teste. Esse é um problema que ocorre quando eu faço logon no servidor de desenvolvimento remoto usando 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.

(os nomes dos arquivos foram alterados para proteger os culpados ...!)

Ambas as caixas executam o Solaris 10 AMD. Eu fiz algumas pesquisas, se eu adicionar --upload-pack=$(which git-upload-pack)o comando funciona (e prova que $PATHcontém o caminho para 'git-upload-pack' conforme a solução RTFM), mas isso é realmente irritante, mais 'git push' não funciona, porque não acho que exista uma --unpack=opção.

Aliás, todos os comandos git funcionam bem na minha caixa local, é a mesma versão do software (1.5.4.2), instalada na mesma montagem NFS em /usr/local/bin.

Alguém pode ajudar?

Verifique se git-upload-packestá no caminho a partir de um shell que não é de login. (Na minha máquina está /usr/bin).

Para ver como é o seu caminho na máquina remota a partir de um shell que não é de login, tente o seguinte:

ssh you@remotemachine echo \$PATH

(Isso funciona em Bash, Zsh e tcsh, e provavelmente em outras conchas também.)

Se o caminho retornado não incluir o diretório que possui git-upload-pack, você precisará corrigi-lo configurando-o .bashrc(para Bash), .zshenv(para Zsh), .cshrc(para tcsh) ou equivalente para seu shell.

Você precisará fazer essa alteração na máquina remota.

Se você não tiver certeza de qual caminho precisa adicionar ao seu controle remoto PATH, poderá encontrá-lo com este comando (é necessário executar isso na máquina remota):

which git-upload-pack

Na minha máquina que imprime /usr/bin/git-upload-pack. Portanto, neste caso, /usr/biné o caminho que você precisa para garantir que está no seu shell remoto sem login PATH.

Você também pode usar a opção "-u" para especificar o caminho. Acho isso útil em máquinas onde meu .bashrc não é obtido em sessões não interativas. Por exemplo,

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

Com base na resposta de Brian , o caminho do pacote de upload pode ser definido permanentemente executando os seguintes comandos após a clonagem, o que elimina a necessidade de --upload-packsolicitações subsequentes de recebimento / retirada. Da mesma forma, a configuração do pacote de recebimento elimina a necessidade de --receive-packsolicitações push.

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

Esses dois comandos são equivalentes a adicionar as seguintes linhas a um repo .git/config.

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

Usuários frequentes de clone -upodem estar interessados ​​nos seguintes aliases. myclone deve ser auto-explicativo. myfetch / mypull / mypush pode ser usado em repositórios cuja configuração não foi modificada conforme descrito acima, substituindo git pushpor git mypush, e assim por diante.

[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

Encontrei e usei (com êxito) esta correção:

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

Graças a Paul Johnston .

O Mac OS X e alguns outros Unixes têm pelo menos o caminho do usuário compilado no sshd por motivos de segurança, para que aqueles que instalam o git como / usr / local / git / {bin, lib, ...} possam ter problemas, pois o git executáveis ​​não estão no caminho pré-compilado. Para substituir isso, prefiro editar minha alteração do / etc / sshd_config:

#PermitUserEnvironment no

para

PermitUserEnvironment yes

e crie arquivos ~ / .ssh / environment conforme necessário. Meus usuários git têm o seguinte em seu arquivo ~ / .ssh / environment:

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

Observe que a expansão da variável não ocorre quando o arquivo ~ / .ssh / environment é lido, portanto:

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

não funciona.

A solução de Matt não funcionou para mim no OS X, mas a de Paul funcionou.

A versão curta do link de Paul é:

Criado /usr/local/bin/ssh_sessioncom o seguinte texto:

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

Executar:

chmod +x /usr/local/bin/ssh_session

Adicione o seguinte a /etc/sshd_config:

ForceCommand / usr / local / bin / ssh_session

Para o bash, ele precisa ser colocado em .bashrc e não em .bash_profile (.bash_profile também é apenas para shells de login).

Eu recebi esses erros com a versão MsysGit.

Depois de seguir todos os conselhos que encontrei aqui e em outros lugares, acabei:

instalando a versão Cygwin do Git

no servidor (Win XP com Cygwin SSHD), isso finalmente foi corrigido.

Eu ainda uso o lado do cliente da versão MsysGit

..de fato, é a única maneira que funciona para mim, já que recebo erros POSIX com o Cygwin Git pull desse mesmo servidor sshd

Eu suspeito que ainda é necessário algum trabalho deste lado do uso do Git .. (ssh + facilidade de puxar / empurrar no Windows)

Como Johan apontou muitas vezes, seu .bashrc é necessário:

ln -s .bash_profile .bashrc

Você deve adicionar o

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

antes desta linha no .bashrc:

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

Caso contrário, todas as instruções de exportação não serão executadas ( veja aqui ).

Meu caso está no Win 10 com o GIT bash e não tenho um GIT no local padrão. Em vez disso, tenho o git em / app / local / bin. Usei os comandos fornecidos pelo @Garrett, mas preciso alterar o caminho para começar com o dobro /:

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

Caso contrário, o GIT adicionará o caminho do Windows GIT na frente.

Para o zsh, você precisa colocá-lo neste arquivo: ~ / .zshenv

Por exemplo, no OS X usando o pacote git-core do MacPorts:

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

Estou tendo problemas para conectar-me a um repositório Gitolite usando SSH do Windows e o problema foi PLINK! Ele ficava me pedindo uma senha, mas o ssh gitolite @ [host] retornava a lista de recompra.

Verifique sua variável de ambiente: GIT_SSH. Se estiver definido como Plink, tente-o sem nenhum valor ("defina GIT_SSH =") e veja se isso funciona.

Adicione o local do seu git-upload-packarquivo .bashrc do usuário remoto do git.

Pode ser tão simples quanto instalar o git no host remoto (como no meu caso).

sudo apt-get install git

Ou equivalente para outros sistemas de gerenciamento de pacotes.