remota - git-upload-pack: comando no encontrado, al clonar el repositorio remoto de Git

github tutorial español (13)

Agregue la ubicación de su git-upload-pack al archivo .bashrc del usuario remoto de git.

He estado usando git para mantener sincronizadas dos copias de mi proyecto, una es mi buzón local y la otra el servidor de prueba. Este es un problema que ocurre cuando inicio sesión en nuestro servidor de desarrollo 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.

(¡los nombres de los archivos han sido cambiados para proteger al culpable ...!)

Ambas cajas ejecutan Solaris 10 AMD. He hecho algunas excavaciones, si agrego --upload-pack=$(which git-upload-pack) el comando funciona, (y demuestra que $PATH contiene la ruta a ''git-upload-pack'' según la solución RTFM ) pero esto es realmente molesto, más ''git push'' no funciona, porque no creo que haya una opción --unpack= .

A propósito, todos los comandos de git funcionan bien desde mi cuadro local, es la misma versión del software (1.5.4.2), instalada en el mismo montaje de NFS en /usr/local/bin .

¿Alguien puede ayudar?

Asegúrese de que git-upload-pack esté en la ruta desde un shell que no sea de inicio de sesión. (En mi máquina está en /usr/bin ).

Para ver cómo se ve tu camino en la máquina remota desde un shell que no es de inicio de sesión, prueba esto:

ssh you@remotemachine echo /$PATH

(Eso funciona en Bash, Zsh y tcsh, y probablemente también en otros shells).

Si la ruta que devuelve no incluye el directorio que tiene git-upload-pack , debe corregirlo configurándolo en .bashrc (para Bash), .zshenv (para Zsh), .cshrc (para tcsh) o equivalente para tu caparazón.

Tendrá que hacer este cambio en la máquina remota.

Si no está seguro de qué camino debe agregar a su PATH remota, puede encontrarlo con este comando (debe ejecutar esto en la máquina remota):

which git-upload-pack

En mi máquina que imprime /usr/bin/git-upload-pack . Entonces, en este caso, /usr/bin es la ruta que debe asegurarse de que esté en su PATH remoto que no es de inicio de sesión.

Como Johan señaló muchas veces su .bashrc que se necesita:

ln -s .bash_profile .bashrc

Debes agregar el

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

antes de esta línea en .bashrc:

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

De lo contrario, no se ejecutarán todas las declaraciones de exportación ( ver aquí ).

Encontré y usé (con éxito) esta corrección:

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

Gracias a Paul Johnston .

He tenido problemas para conectarme a un repositorio de Gitolite usando SSH de Windows y resultó que mi problema era PLINK. Me seguía pidiendo una contraseña, pero el ssh gitolite @ [host] devolvería la lista de repo bien.

Verifica tu variable de entorno: GIT_SSH. Si está establecido en Plink, entonces pruébelo sin ningún valor ("set GIT_SSH =") y vea si eso funciona.

La solución de Matt no funcionó para mí en OS X, pero la de Paul sí.

La versión corta del enlace de Paul es:

Creado /usr/local/bin/ssh_session con el siguiente 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

Ejecutar:

chmod +x /usr/local/bin/ssh_session

Agregue lo siguiente a /etc/sshd_config :

ForceCommand / usr / local / bin / ssh_session

Mac OS X y algunos otros Unix al menos tienen la ruta del usuario compilada en sshd por razones de seguridad, por lo que aquellos de nosotros que instalamos git como / usr / local / git / {bin, lib, ...} pueden tener problemas como el git los ejecutables no están en la ruta precompilada. Para anular esto, prefiero editar mi cambio de / etc / sshd_config:

#PermitUserEnvironment no

PermitUserEnvironment yes

y luego crea archivos ~ / .ssh / environment según sea necesario. Mis usuarios de git tienen lo siguiente en su archivo ~ / .ssh / environment:

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

La expansión de variable de nota no se produce cuando el archivo ~ / .ssh / environment se lee así:

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

no trabajará.

Obtuve estos errores con la versión de MsysGit.

Después de seguir todos los consejos que pude encontrar aquí y en otros lugares, terminé:

instalar la versión Cygwin de Git

en el servidor (Win XP con Cygwin SSHD), esto finalmente lo solucionó.

Todavía uso el lado del cliente de la versión MsysGit

..de hecho, es la única forma en que funciona para mí, ya que tengo errores POSIX con el tirón de Cygwin Git del mismo servidor sshd

Sospecho que todavía se necesita algo de trabajo de este lado del uso de Git ... (ssh + facilidad de extracción / inserción en Windows)

Para bash, necesita ser puesto en .bashrc no .bash_profile (.bash_profile también es solo para shells de inicio de sesión).

Para zsh necesitas ponerlo en este archivo: ~ / .zshenv

Por ejemplo, en OS X usando el paquete git-core de MacPorts:

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

Sobre la base de la respuesta de Brian , la ruta del paquete de carga se puede establecer permanentemente ejecutando los siguientes comandos después de la clonación, lo que elimina la necesidad de --upload-pack en las siguientes solicitudes de extracción / recuperación. De manera similar, al establecer el paquete de recepción se elimina la necesidad de --receive-pack en solicitudes de inserción.

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

Estos dos comandos son equivalentes a agregar las siguientes líneas a un .git/config del repositorio.

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

Los usuarios frecuentes de clone -u pueden estar interesados en los siguientes alias. myclone debería ser autoexplicativo. myfetch / mypull / mypush se puede usar en repositorios cuya configuración no se haya modificado como se describe arriba reemplazando git push con git mypush , y así sucesivamente.

[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

También puede usar la opción "-u" para especificar la ruta. Encuentro esto útil en máquinas donde mi .bashrc no se obtiene en sesiones no interactivas. Por ejemplo,

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