git-upload-pack: commande introuvable, lors du clonage du dépôt Git distant

J'utilise git pour synchroniser deux copies de mon projet, l'une est ma boîte locale, l'autre le serveur de test. C'est un problème qui 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 de fichiers ont été modifiés pour protéger les coupables ...!)

Les deux boîtiers exécutent Solaris 10 AMD. J'ai fait quelques recherches, si j'ajoute --upload-pack=$(which git-upload-pack)la commande fonctionne, (et prouve qu'elle $PATHcontient le chemin vers 'git-upload-pack' selon la solution RTFM) mais c'est vraiment ennuyeux, plus 'git push' ne fonctionne pas, parce que je ne pense pas qu'il y ait une --unpack=option.

Incidemment, toutes les commandes git fonctionnent correctement à partir de ma boîte locale, c'est la même version du logiciel (1.5.4.2), installée sur le même montage NFS à /usr/local/bin.

Quelqu'un peut-il aider?

Assurez-vous qu'il se git-upload-packtrouve sur le chemin d'un shell non connecté. (Sur ma machine, c'est dedans /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 rend n'inclut pas le répertoire qui a git-upload-pack, vous devez le corriger en le définissant dans .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 ne savez pas quel chemin 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/binest le chemin dont vous devez vous assurer qu'il se trouve dans votre shell distant sans connexion PATH.

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

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

En s'appuyant sur la réponse de Brian , le chemin de téléchargement du pack peut être défini de manière permanente en exécutant les commandes suivantes après le clonage, ce qui élimine le besoin de --upload-packrequêtes d'extraction / extraction ultérieures. De même, la configuration de receive-pack élimine le besoin de --receive-packdemandes 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 à un dépôt .git/config.

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

Les utilisateurs fréquents de clone -upeuvent être intéressés par les alias suivants. myclone doit être explicite. 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 pushpar 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

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 .

Mac OS X et certains autres Unix ont au moins le chemin utilisateur compilé dans sshd pour des raisons de sécurité, donc ceux d'entre nous qui installent git comme / usr / local / git / {bin, lib, ...} peuvent rencontrer des problèmes en tant que git les exécutables ne se trouvent pas dans le chemin précompilé. Pour remplacer cela, je préfère modifier mon / etc / sshd_config en changeant:

#PermitUserEnvironment no

à

PermitUserEnvironment yes

puis créez les fichiers ~ / .ssh / environnement selon vos besoins. Mes utilisateurs git ont ce qui suit 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 / environment est lu ainsi:

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

ne fonctionnera pas.

La solution de Matt n'a pas fonctionné pour moi sur OS X, mais celle de Paul.

La version courte du lien de Paul est:

Créé /usr/local/bin/ssh_sessionavec le texte suivant:

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

Exécuter:

chmod +x /usr/local/bin/ssh_session

Ajoutez ce qui suit à /etc/sshd_config:

ForceCommand / usr / local / bin / ssh_session

Pour bash, il doit être placé dans .bashrc et non dans .bash_profile (.bash_profile est également uniquement pour les shells de connexion).

J'ai eu ces erreurs avec la version MsysGit.

Après avoir suivi tous les conseils que j'ai pu trouver ici et ailleurs, je me suis retrouvé:

installer la version Cygwin de Git

sur le serveur (Win XP avec Cygwin SSHD), cela l'a finalement corrigé.

J'utilise toujours le côté client de la version MsysGit

... en fait, c'est la seule façon dont cela fonctionne pour moi, car j'obtiens des erreurs POSIX avec le pull Cygwin Git de ce même serveur sshd

Je soupçonne que du travail est encore nécessaire de ce côté de l'utilisation de Git. (Ssh + facilité de pull / push sous Windows)

Comme Johan l'a souligné à plusieurs reprises, son .bashrc est nécessaire:

ln -s .bash_profile .bashrc

Vous devez ajouter le

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

avant cette ligne dans le .bashrc:

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

Sinon, toutes les instructions d'exportation ne seront pas exécutées ( voir ici ).

Mon cas est sur Win 10 avec GIT bash et je n'ai pas de GIT sous l'emplacement standard. Au lieu de cela, j'ai git sous / app / local / bin. J'ai utilisé les commandes fournies par @Garrett mais je dois changer le chemin pour commencer par double /:

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

Sinon, le GIT ajoutera votre chemin Windows GIT à l'avant.

Pour zsh, vous devez le mettre dans ce fichier: ~ / .zshenv

Par exemple, sur OS X en utilisant le package git-core de MacPorts:

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

J'ai eu des problèmes de connexion à un référentiel Gitolite en utilisant SSH à partir de Windows et il s'est avéré que mon problème était PLINK! Il n'arrêtait pas de me demander un mot de passe, mais le ssh gitolite @ [host] renverrait la liste des dépôts très bien.

Vérifiez votre variable d'environnement: GIT_SSH. S'il est défini sur Plink, essayez-le sans aucune valeur ("set GIT_SSH =") et voyez si cela fonctionne.

Ajoutez l'emplacement de votre git-upload-packau fichier .bashrc de l'utilisateur git distant.

Cela peut être aussi simple que d'installer git sur l'hôte distant (comme c'était le cas dans mon cas).

sudo apt-get install git

Ou équivalent pour d'autres systèmes de gestion de paquets.