git-upload-pack: comando não encontrado, quando a clonagem remoto repo Git
-
03-07-2019 - |
Pergunta
Eu tenho usado o git para manter duas cópias do meu projeto em sincronia, um é minha caixa local, o outro servidor do teste. Este é um problema que ocorre ao efetuar logon no nosso 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.
(o arquivo nomes foram alterados para proteger o culpado ...!)
Ambas as caixas correr Solaris 10 AMD. Eu tenho feito algumas escavações, se eu adicionar --upload-pack=$(which git-upload-pack)
o comando funciona, (e prova que $PATH
contém o caminho para 'git-upload-pack' de acordo com a solução RTFM), mas este é realmente irritante, plus 'git push' não trabalho, porque eu não acho que há uma opção --unpack=
.
Aliás, todo o git comandos funcionam bem de minha caixa de local, é a mesma versão do software (1.5.4.2), instalados no mesmo NFS montar a /usr/local/bin
.
Alguém pode ajudar?
Solução
Certifique-se de git-upload-pack
está no caminho de um shell não login. (Na minha máquina está em /usr/bin
).
Para ver o que sua aparência caminho como na máquina remota a partir de um shell não login, tente o seguinte:
ssh you@remotemachine echo \$PATH
(que funciona em Bash, Zsh, e tcsh, e provavelmente outras conchas também.)
Se o caminho que dá para trás não inclui o diretório que tem git-upload-pack
, você precisa corrigi-lo, colocando-o em .bashrc
(para Bash), .zshenv
(para Zsh), .cshrc
(para tcsh) ou equivalente para o seu shell .
Você precisará fazer essa alteração na máquina remota.
Se você não tiver certeza qual o caminho que você precisa para adicionar à sua PATH
remoto, você pode encontrá-lo com este comando (você precisa executar este 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 ter certeza está na sua PATH
shell não login remoto.
Outras dicas
Você também pode usar a opção "-u" para especificar o caminho. I encontrar este útil em máquinas onde o meu .bashrc não se originados em sessões não-interativas. Por exemplo,
git clone -u /home/you/bin/git-upload-pack you@machine:code
Com base na Brian de responder , o caminho do upload-pack pode ser definido de forma permanente, executando os seguintes comandos após a clonagem, o que elimina a necessidade de --upload-pack
em puxar posterior / solicitações de busca. Da mesma forma, configuração receber-pack elimina a necessidade de --receive-pack
em solicitações de envio.
git config remote.origin.uploadpack /path/to/git-upload-pack
git config remote.origin.receivepack /path/to/git-receive-pack
Estes dois comandos são equivalentes a adicionando as seguintes linhas para .git/config
um repo.
[remote "origin"]
uploadpack = /path/to/git-upload-pack
receivepack = /path/to/git-receive-pack
Os usuários freqüentes de clone -u
pode estar interessado nos seguintes aliases. myclone deve ser auto-explicativo. myfetch / mypull / mypush pode ser utilizado em operações de reporte cuja configuração não tenha sido modificada como descrito acima, substituindo git push
com 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
I encontrado e utilizado (com sucesso) essa correção:
# Fix it with symlinks in /usr/bin
$ cd /usr/bin/
$ sudo ln -s /[path/to/git]/bin/git* .
Graças à Paul Johnston .
Mac OS X e alguns outros Unixes, pelo menos, tem o caminho usuário compilados em sshd por razões de segurança, para aqueles de nós que instalar git como / usr / local / git / {bin, lib, ...} pode ter problemas como os executáveis ??git não estão no caminho pré-compilada. Para substituir esse eu prefiro editar o meu / etc / sshd_config mudando:
#PermitUserEnvironment no
para
PermitUserEnvironment yes
arquivos e, em seguida, criar ~ / .ssh / ambiente, conforme necessário. Meus usuários git ter o seguinte em seu arquivo ~ / .ssh / ambiente:
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/git/bin
expansão Nota variável não ocorre quando o arquivo ~ / .ssh / ambiente é lido assim:
PATH=$PATH:/usr/local/git/bin
não vai funcionar.
Para bash, ele precisa ser colocado em .bashrc não .bash_profile (.bash_profile é também apenas para shells de login).
A solução de Matt não funcionou para mim no OS X, mas Paulo fez.
A versão curta de ligação de Paulo é:
Criado /usr/local/bin/ssh_session
com 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 ao /etc/sshd_config
:
ForceCommand / usr / local / bin / ssh_session
Eu tenho esses erros com a versão msysgit.
Depois de seguir todos os conselhos que eu poderia encontrar aqui e em outros lugares, acabei:
instalar a versão Cygwin do Git
no servidor (Win XP com Cygwin SSHD), este, finalmente, fixa-lo.
Eu ainda uso o lado do cliente versão msysgit
.. na verdade, é a única maneira que trabalha para mim, pois eu recebo erros POSIX com a atração Cygwin Git a partir dessa mesma servidor sshd
Eu suspeito que algum trabalho ainda é necessária neste lado do uso Git .. (Ssh + facilidade de puxar / empurrar no Windows)
Como Johan gótico muitas vezes o seu .bashrc que é necessário:
ln -s Bash_profile .bashrc
Você deve adicionar o
export PATH=/opt/git/bin:$PATH
antes desta linha na .bashrc:
# If not running interactively, don't do anything
[ -z "$PS1" ] && return
Caso contrário, todas as declarações de exportação não será executado ( veja aqui ).
Para zsh você precisa colocá-lo neste arquivo: ~ / .zshenv
Por exemplo, no OS X usando o pacote git-core a partir MacPorts:
$ echo 'export PATH = / opt / local / sbin: / opt / local / bin: $ PATH'> ~ / .zshenv
Eu tenho tido problemas para se conectar a um Gitolite repo usando SSH a partir do Windows e descobriu-se que o meu problema era Plink! Ele ficava me perguntando por uma senha, mas o gitolite ssh @ [host] voltaria a lista repo bem.
Verifique se o seu variável de ambiente: GIT_SSH. Se ele estiver definido para Plink, em seguida, experimentá-lo sem qualquer valor ( "set GIT_SSH =") e ver se isso funciona.
Adicionar a localização do seu git-upload-pack
para arquivo .bashrc do usuário git remoto.