git-upload-pack : commande non trouvée, lors du clonage d'un repo Git distant

Question

J'ai utilisé git pour garder deux copies de mon projet en synchronisation, l'une est ma boîte locale, l'autre le serveur de test. Le problème se produit lorsque je me connecte à notre serveur de développement distant en utilisant 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.

(les noms des fichiers ont été modifiés pour protéger les coupables... !)

Les deux boîtes fonctionnent sous Solaris 10 AMD. J'ai fait quelques recherches, si j'ajoute --upload-pack=$(which git-upload-pack) la commande fonctionne, (et prouve que $PATH contient le chemin vers 'git-upload-pack' comme dans la solution RTFM) mais c'est vraiment ennuyeux, de plus 'git push' ne fonctionne pas, parce que je ne pense pas qu'il y ait un fichier --unpack= option.

Par ailleurs, toutes les commandes git fonctionnent bien depuis ma boîte locale, il s'agit de la même version du logiciel (1.5.4.2), installée sur le même support NFS à l'adresse suivante /usr/local/bin .

Quelqu'un peut-il m'aider ?

Answer 1

Assurez-vous que git-upload-pack est sur le chemin depuis un shell non connecté. (Sur ma machine, c'est dans /usr/bin ).

Pour voir à quoi ressemble votre chemin sur la machine distante à partir d'un shell sans connexion, essayez ceci :

ssh you@remotemachine echo \$PATH

(Cela fonctionne dans Bash, Zsh, et tcsh, et probablement d'autres shells aussi).

Si le chemin qu'il renvoie n'inclut pas le répertoire qui a git-upload-pack vous devez le corriger en l'insérant dans le fichier .bashrc (pour Bash), .zshenv (pour Zsh), .cshrc (pour tcsh) ou équivalent pour votre shell.

Vous devrez effectuer cette modification sur la machine distante.

Si vous n'êtes pas sûr du chemin que vous devez ajouter à votre télécommande PATH vous pouvez le trouver avec cette commande (vous devez l'exécuter sur la machine distante) :

which git-upload-pack

Sur ma machine qui imprime /usr/bin/git-upload-pack . Donc dans ce cas, /usr/bin est le chemin dont vous devez vous assurer qu'il se trouve dans votre shell distant sans login. PATH .

Answer 2

Vous pouvez également utiliser l'option "-u" pour spécifier le chemin. Je trouve cela utile sur les machines où mon .bashrc n'a pas de source dans les sessions non-interactives. Par exemple,

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

Answer 3

Construire sur Réponse de Brian le chemin du pack d'envoi peut être défini de manière permanente en exécutant les commandes suivantes après le clonage, ce qui élimine le besoin d'utiliser la fonction d'envoi de paquets. --upload-pack sur les requêtes pull/fetch suivantes. De même, la configuration de receive-pack élimine le besoin de --receive-pack sur les demandes de push.

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

Ces deux commandes sont équivalentes à l'ajout des lignes suivantes dans le fichier de référence d'un repo .git/config .

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

Les utilisateurs fréquents de clone -u peut être intéressé par les alias suivants. myclone devrait être auto-explicatif. myfetch/mypull/mypush peut être utilisé sur les dépôts dont la configuration n'a pas été modifiée comme décrit ci-dessus en remplaçant git push avec git mypush et ainsi de suite.

[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

Answer 4

J'ai trouvé et utilisé (avec succès) ce correctif :

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

Merci à Paul Johnston .

Answer 5

Mac OS X et certains autres Unixes ont au moins le chemin de l'utilisateur compilé dans sshd pour des raisons de sécurité. Ceux d'entre nous qui installent git sous /usr/local/git/{bin,lib,...} peuvent avoir des problèmes car les exécutables de git ne sont pas dans le chemin précompilé. Pour contourner cela, je préfère éditer mon /etc/sshd_config en le modifiant :

#PermitUserEnvironment no

à

PermitUserEnvironment yes

puis créez des fichiers ~/.ssh/environnement si nécessaire. Mes utilisateurs de git ont les éléments suivants dans leur fichier ~/.ssh/environnement :

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

Notez que l'expansion des variables ne se produit pas lorsque le fichier ~/.ssh/environnement est lu ainsi :

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

ne fonctionnera pas.