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?

Foi útil?

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.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top