git-upload-pack: comando non trovato, durante la clonazione del repository Git remoto

Ho usato git per sincronizzare due copie del mio progetto, una è la mia casella locale, l'altra il server di prova. Questo è un problema che si verifica quando accedo al nostro server di sviluppo 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.

(i nomi dei file sono stati cambiati per proteggere i colpevoli ...!)

Entrambe le scatole eseguono Solaris 10 AMD. Ho fatto qualche ricerca, se aggiungo --upload-pack=$(which git-upload-pack)il comando funziona (e dimostra che $PATHcontiene il percorso di 'git-upload-pack' come per la soluzione RTFM) ma questo è davvero fastidioso, più 'git push' non funziona, perché non penso che ci sia --unpack=un'opzione.

Per inciso, tutti i comandi git funzionano bene dalla mia casella locale, è la stessa versione del software (1.5.4.2), installato sullo stesso mount NFS su /usr/local/bin.

Qualcuno può aiutare?

Assicurarsi che git-upload-packsi trovi sul percorso da una shell non di accesso. (Sulla mia macchina è dentro /usr/bin).

Per vedere come appare il tuo percorso sul computer remoto da una shell non di accesso, prova questo:

ssh you@remotemachine echo \$PATH

(Funziona in Bash, Zsh e tcsh, e probabilmente anche in altre shell.)

Se il percorso che restituisce non include la directory che ha git-upload-pack, è necessario correggerlo impostandolo in .bashrc(per Bash), .zshenv(per Zsh), .cshrc(per tcsh) o equivalente per la shell.

Sarà necessario apportare questa modifica sul computer remoto.

Se non sei sicuro di quale percorso devi aggiungere al tuo telecomando PATH, puoi trovarlo con questo comando (devi eseguirlo sul computer remoto):

which git-upload-pack

Sulla mia macchina che stampa /usr/bin/git-upload-pack. Quindi, in questo caso, /usr/binè il percorso che è necessario assicurarsi sia nella shell remota non di accesso PATH.

Puoi anche usare l'opzione "-u" per specificare il percorso. Lo trovo utile su macchine in cui il mio .bashrc non proviene da sessioni non interattive. Per esempio,

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

Basandosi sulla risposta di Brian , il percorso di upload-pack può essere impostato in modo permanente eseguendo i seguenti comandi dopo la clonazione, il che elimina la necessità di --upload-packsuccessive richieste pull / fetch. Allo stesso modo, l'impostazione di ricezione-pacchetto elimina la necessità di --receive-packrichieste push.

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

Questi due comandi equivalgono ad aggiungere le seguenti righe ai repository .git/config.

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

Gli utenti frequenti di clone -upotrebbero essere interessati ai seguenti alias. myclone dovrebbe essere autoesplicativo. myfetch / mypull / mypush può essere utilizzato su repository la cui configurazione non è stata modificata come descritto sopra sostituendo git pushcon git mypush, e così via.

[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

Ho trovato e usato (con successo) questa correzione:

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

Grazie a Paul Johnston .

Mac OS X e alcuni altri Unix hanno almeno il percorso dell'utente compilato in sshd per motivi di sicurezza, quindi quelli di noi che installano git come / usr / local / git / {bin, lib, ...} possono incorrere in problemi come git gli eseguibili non si trovano nel percorso precompilato. Per ignorare questo, preferisco modificare il mio / etc / sshd_config cambiando:

#PermitUserEnvironment no

per

PermitUserEnvironment yes

e quindi creare i file ~ / .ssh / environment secondo necessità. I miei utenti git hanno i seguenti nel loro file ~ / .ssh / environment:

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

Nota l'espansione della variabile non si verifica quando il file ~ / .ssh / environment viene letto in questo modo:

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

non funzionerà.

La soluzione di Matt non ha funzionato per me su OS X, ma ha fatto Paul.

La versione breve dal link di Paul è:

Creato /usr/local/bin/ssh_sessioncon il seguente testo:

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

Eseguire:

chmod +x /usr/local/bin/ssh_session

Aggiungi quanto segue a /etc/sshd_config:

ForceCommand / usr / local / bin / ssh_session

Per bash, deve essere inserito in .bashrc e non .bash_profile (.bash_profile è anche solo per le shell di login).

Ho riscontrato questi errori con la versione MsysGit.

Dopo aver seguito tutti i consigli che ho trovato qui e altrove, sono finito:

l'installazione della versione Cygwin di Git

sul server (Win XP con Cygwin SSHD), questo finalmente risolto.

Uso ancora il lato client della versione MsysGit

..in effetti, è l'unico modo in cui funziona per me, dal momento che ottengo errori POSIX con il pull di Cygwin Git dallo stesso server sshd

Sospetto che sia ancora necessario un po 'di lavoro da questo lato dell'uso di Git .. (ssh + facilità di pull / push in Windows)

Come Johan ha sottolineato molte volte il suo .bashrc che è necessario:

ln -s .bash_profile .bashrc

Devi aggiungere il

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

prima di questa riga nel .bashrc:

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

In caso contrario, tutte le dichiarazioni di esportazione non verranno eseguite ( vedere qui ).

Il mio caso è su Win 10 con GIT bash e non ho un GIT in posizione standard. Invece ho git in / app / local / bin. Ho usato i comandi forniti da @Garrett ma devo cambiare il percorso per iniziare con double /:

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

Altrimenti GIT aggiungerà il percorso GIT di Windows in primo piano.

Per zsh devi metterlo in questo file: ~ / .zshenv

Ad esempio, su OS X usando il pacchetto git-core di MacPorts:

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

Ho avuto problemi di connessione a un repository Gitolite utilizzando SSH da Windows e si è scoperto che il mio problema era PLINK! Continuava a chiedermi una password, ma ssh gitolite @ [host] restituiva bene l'elenco dei repository.

Controlla la variabile di ambiente: GIT_SSH. Se è impostato su Plink, provalo senza alcun valore ("set GIT_SSH =") e vedi se funziona.

Aggiungi la tua posizione git-upload-packal file .bashrc dell'utente remoto di git.

Potrebbe essere semplice come installare git sull'host remoto (come nel mio caso).

sudo apt-get install git

O equivalente per altri sistemi di gestione dei pacchetti.