Me encontré con el mismo problema con un sitio que había alojado en un paquete de alojamiento compartido HostNine. También le dan sshacceso, pero desafortunadamente no se han gitinstalado y ni siquiera le dan acceso para ejecutar gcc, lo que dificulta la descarga e instalación de git para su usuario.
La única forma en que podía pensar para evitar estas restricciones era copiar los binarios de git desde otra computadora que los tuviera. Quizás la misma solución funcionaría para usted y su host compartido GoDaddy. Esto es lo que hice:
Primero descubra qué arquitectura tiene su servidor. En mi caso fue de 32 bits (i386). Aquí hay un par de formas de resolverlo:
# uname -a
Linux ___.myserverhosts.com 2.6.18-128.1.6.el5PAE #1 SMP Wed Apr 1 10:02:22 EDT 2009 i686 i686 i386 GNU/Linux
# file /bin/echo
/bin/echo: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
A continuación, debe encontrar otra computadora que ejecute Linux con la misma arquitectura y con git instalado. Ni siquiera tienen que estar ejecutando la misma distribución o versión de Linux, siempre y cuando tengan la misma arquitectura y pueda encontrar los archivos binarios y la biblioteca que necesita.
Para encontrar la ubicación del binario git principal:
> which git
/usr/local/bin/git
Algunos otros archivos binarios importantes (como git-receive-pack) también residen en el mismo directorio, por lo que recomiendo simplemente copiar todo /usr/local/bin/git*para asegurarse de obtener todo lo que necesita.
Otros archivos importantes son de los que depende git están bajo un directorio 'libexec' en algún lugar del sistema fuente. Si no los copia, es posible que reciba un mensaje de error sorprendente cuando intente hacer git push, como hice yo:
git: 'index-pack' is not a git-command. See 'git --help'.
Para encontrar el directorio que contiene las bibliotecas principales de git en target_host, puede usar esto:
> git --exec-path
/usr/local/libexec/git-core
Recomendaría copiar esos archivos primero y luego intentar ejecutar git para ver si se queja de las bibliotecas compartidas faltantes. Si no es así, entonces eres (presumiblemente) bueno para ir. Si es así, sigue leyendo. (No use copiar sobre bibliotecas compartidas si ya existen en el host de destino y son la versión correcta).
Puede copiar los archivos con scp, rsync, ftp, o lo que usted se sienta cómodo. Solía scpalgo como esto:
> ssh target_host 'mkdir -p ~/bin ~/libexec'
> scp /usr/local/bin/git* target_host:~/bin
> scp -r /usr/local/libexec/git-core target_host:~/libexec
Luego ssh a target_host. Deberá agregar algunas líneas como estas a su ~/.bashrc:
export PATH=$PATH:~/bin
export LD_LIBRARY_PATH=~/lib
export GIT_EXEC_PATH=~/libexec/git-core
Si olvida este paso, es posible que se sorprenda al ver este error cuando hace un git push:
git-receive-pack: command not found
Esto está documentado en las preguntas frecuentes de Git en git.or.cz:
Básicamente, el problema es que 'git-recibir-paquete' no está en el $ PATH predeterminado en el extremo remoto.
...
- Asegurarse de que tiene la ruta correcta configurada
.bashrc(no solo .bash_profile)
GIT_EXEC_PATHestá documentado en man git:
--exec-path
Path to wherever your core git programs are installed.
This can also be controlled by setting the GIT_EXEC_PATH
environment variable. If no path is given, git will print
the current setting and then exit.
Fuente de su nuevo ~/.bashrc. Ahora intenta correr git.
Esto es lo que me dio la primera vez:
> git
git: error while loading shared libraries: libcrypto.so.4: cannot open shared object file: No such file or directory
Pude averiguar la ubicación de las bibliotecas compartidas para copiar ejecutando esto en la máquina de origen:
> ldd /usr/local/bin/git
libz.so.1 => /usr/lib/libz.so.1 (0xb7fcf000)
libcrypto.so.4 => /lib/libcrypto.so.4 (0xb7ee4000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7ed2000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7da6000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb7d92000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7d2d000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7d2a000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7d08000)
libresolv.so.2 => /lib/libresolv.so.2 (0xb7cf5000)
libdl.so.2 => /lib/libdl.so.2 (0xb7cf1000)
/lib/ld-linux.so.2 (0xb7fe8000)
En mi caso, yo sólo tenía que copiar /lib/libcrypto.so.4a ~/libmi target_hosty todo estaba bien.
¡Ahora debería trabajar giten su servidor de alojamiento compartido y debería poder impulsarlo!
Ahora debe crear un nuevo repositorio git y un árbol de trabajo en su servidor o copiar su repositorio / árbol de trabajo existente.
Por cierto, no creo que un repositorio desnudo sea lo que desea en el servidor en este caso, ya que dijo que quería implementar los archivos de contenido reales (en lugar de solo los config HEAD objects/ refs/archivos que se incluirían en un repositorio desnudo) siempre tu haces a git push.
toolmantim.com explica la diferencia entre un repositorio git regular y un repositorio simple :
Un repositorio git predeterminado asume que lo usará como su directorio de trabajo, por lo que git almacena los archivos reales del repositorio desnudo en un directorio .git junto con todos los archivos del proyecto. Los repositorios remotos no necesitan copias de los archivos en el sistema de archivos a diferencia de las copias de trabajo, todo lo que necesitan son los deltas y las cosas binarias del repositorio en sí. Esto es lo que "desnudo" significa git. Solo el repositorio en sí.
Asumiré por el momento que ya ha creado un directorio en el target_hostque desea implementar su sitio web (o lo que sea que esté implementando). Llamemos a ese directorio ~/www/my_site. Es posible que incluso haya ftp'd sobre todos sus archivos ~/www/my_site already. (Tener o no tener no es importante). También asumiré por el momento que aún no ha copiado el subdirectorio .git ~/www/my_site(aunque debería funcionar bien si lo ha hecho).
Como todavía no hay un repositorio de git inicializado en target_host, su primer paso sería crear uno:
> cd ~/www/my_site
> git init
Luego, desde el host que tenga el repositorio con los últimos cambios que desea implementar (su cuadro de desarrollo, supongo), solo tiene que hacer algo como esto para implementar:
> git push --all ssh://username@target_host:port/~/www/my_site/.git
Es posible que vea una advertencia como esta si su repositorio target_hostno está actualizado:
> warning: updating the current branch
> warning: Updating the currently checked out branch may cause confusion,
> warning: as the index and work tree do not reflect changes that are in HEAD.
> warning: As a result, you may see the changes you just pushed into it
> warning: reverted when you run 'git diff' over there, and you may want
> warning: to run 'git reset --hard' before starting to work to recover.
> warning:
> warning: You can set 'receive.denyCurrentBranch' configuration variable to
> warning: 'refuse' in the remote repository to forbid pushing into its
> warning: current branch.
> warning: To allow pushing into the current branch, you can set it to 'ignore';
> warning: but this is not recommended unless you arranged to update its work
> warning: tree to match what you pushed in some other way.
> warning:
> warning: To squelch this message, you can set it to 'warn'.
> warning:
> warning: Note that the default will change in a future version of git
> warning: to refuse updating the current branch unless you have the
> warning: configuration variable set to either 'ignore' or 'warn'.
(En el gituso normal , nunca ves ese mensaje, creo, porque normalmente estás presionando a repositorios desnudos . Pero dado que nuestro repositorio remoto en este caso es un repositorio normal con un árbol de trabajo y un índice, gites comprensiblemente preocupado de que pueda estropear algo.)
Sin embargo, creo que es seguro para nosotros configurarlo para 'ignorar' en su servidor, porque no es probable que realice ninguna confirmación directamente en el repositorio allí. (Todos los commits probablemente deberían originarse en su repositorio de desarrollo y luego ser enviados al servidor).
Así que adelante y configure esto para que no vea la advertencia cada vez que presiona:
> ssh target_host 'cd ~/www/my_site/; git config receive.denyCurrentBranch ignore'
El pushsolo actualiza el índice, sin embargo, NO los archivos en el árbol de trabajo. Sin embargo, actualizar esos archivos es solo el punto completo de lo que estamos tratando de hacer, por lo que nuestro trabajo no se realiza hasta que le indiquemos gitque escriba el contenido del índice en el árbol de trabajo, así:
> ssh target_host 'cd ~/www/my_site/; git reset --hard'
(Nota: Cualquier cambio que haya tenido en su árbol de trabajo en el servidor será sobrescrito por lo que está en el repositorio).
También seguí la sugerencia de mattikus y creé un control remoto para mi servidor:
> git remote add h9 ssh://username@target_host:port/~/www/my_site/.git
Así que ahora todo lo que tengo que hacer para implementar es:
> git push --all --force h9
> ssh remote_host 'cd ~/www/my_site/; git reset --hard'
Incluso fui tan lejos como para lanzar estos comandos en un script que nombré, script/deployasí que cada vez que quiero implementar solo tengo que ejecutar un comando.
Avíseme si encuentra algún error en estas instrucciones o si conoce una solución mejor.