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

Ho usato git per mantenere sincronizzate due copie del mio progetto, una è la mia casella locale, l’altra il server di test. Questo è un problema che si verifica quando accedo al nostro server di sviluppo remoto usando ssh;

git clone [email protected]:/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 '[email protected]:/home/chris/myproject' failed. 

(i nomi dei file sono stati modificati per proteggere i colpevoli …!)

Entrambe le caselle eseguono Solaris 10 AMD. Ho fatto alcuni scavi, se aggiungo --upload-pack=$(which git-upload-pack) il comando funziona (e dimostra che $PATH contiene il percorso di ‘git-upload-pack’ secondo la soluzione RTFM ) ma questo è davvero fastidioso, in più ‘git push’ non funziona, perché non penso ci sia un’opzione --unpack= .

Per inciso, tutti i comandi git funzionano bene dal mio box locale, è la stessa versione del software (1.5.4.2), installata sullo stesso mount NFS su /usr/local/bin .

Qualcuno può aiutare?

Assicurati che git-upload-pack si trovi sul percorso da una shell non di login. (Sulla mia macchina è in /usr/bin ).

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

 ssh [email protected] echo \$PATH 

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

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

Sarà necessario apportare questa modifica sulla macchina remota.

Se non si è sicuri di quale percorso è necessario aggiungere al PATH remoto, è ansible trovarlo con questo comando (è necessario 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 necessario per accertarsi che si trovi nel PATH shell remota non di accesso.

Puoi anche usare l’opzione “-u” per specificare il percorso. Trovo utile su macchine in cui il mio .bashrc non viene acquisito in sessioni non interattive. Per esempio,

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

Basandosi sulla risposta di Brian , il percorso del pacchetto di caricamento può essere impostato in modo permanente eseguendo i seguenti comandi dopo la clonazione, eliminando la necessità di --upload-pack nelle successive richieste di pull / fetch. Allo stesso modo, l’impostazione di ricevere-pack elimina la necessità di --receive-pack sulle richieste 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 a .git/config di un repository.

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

Gli utenti frequenti di clone -u potrebbero essere interessati ai seguenti alias. myclone dovrebbe essere auto-esplicativo. myfetch / mypull / mypush può essere usato su repository la cui configurazione non è stata modificata come descritto sopra sostituendo git push con 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 utilizzato (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 andare incontro a problemi come il git i file eseguibili non si trovano nel percorso precompilato. Per sovrascriverlo preferisco modificare il mio / etc / sshd_config cambiando:

 #PermitUserEnvironment no 

a

 PermitUserEnvironment yes 

e quindi creare file ~ / .ssh / environment secondo necessità. I miei utenti git hanno il seguente 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 così:

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

non funzionerà.

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

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

La versione breve del link di Paolo è:

Creato /usr/local/bin/ssh_session con 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

Ho ricevuto questi errori con la versione MsysGit.

Dopo aver seguito tutti i consigli che ho potuto trovare qui e altrove, ho finito per:

installazione della versione Cygwin di Git

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

Uso ancora la versione client di MsysGit

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

Sospetto che sia ancora necessario un po ‘di lavoro su questo lato 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 in .bashrc:

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

Altrimenti tutte le istruzioni di esportazione non verranno eseguite ( vedere qui ).

Per zsh è necessario inserirlo in questo file: ~ / .zshenv

Ad esempio, su OS X utilizzando il pacchetto git-core da MacPorts:

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

Ho avuto problemi con la connessione a un repository Gitolite usando SSH da Windows e ho scoperto che il mio problema era PLINK! Continuava a chiedermi una password, ma la ssh gitolite @ [host] avrebbe restituito l’elenco dei repo.

Controlla la tua variabile di ambiente: GIT_SSH. Se è impostato su Plink, provalo senza alcun valore (“imposta GIT_SSH =”) e verifica se funziona.

Aggiungi il percorso del tuo git-upload-pack al file .bashrc dell’utente git remoto.