El gancho post-recepción Git no funciona

Estamos usando git con un repository central (usando Gitosis). Creé un enlace posterior a la recepción para generar un correo electrónico a la list de distribución de dev cuando los cambios se envían al repository central y para generar documentation de la carpeta de documentation en el repository de git.

Por lo tanto, en ~ git / Tengo un directory, lo llamaremos 'a' que contiene un clon del git repo. El gancho post-recepción se ve así:

#!/bin/bash cd ~git/repositories/a.git . ~git/post-receive-email &> /dev/null ( cd ~git/a && git pull &> ~git/pull_log.log && php ~git/a/scripts/generate_markdown_documentation.php &> ~git/doc_log.log ) 

El script de correo electrónico funciona, pero la generación de documentation no lo está. El contenido de pull_log.log es:

 fatal: Not a git repository: '.' 

Lo que me hace pensar que no está cambiando al directory correcto en la línea 5 del script anterior. ¿Me equivoco? ¿Cómo puedo hacer que esto funcione?

Editar: he actualizado el enlace posterior a la recepción como se sugiere en las respuestas. El guion es ahora:

 #!/bin/bash function die { echo "$*" >&2; exit 1 } function checkgit { [ -d "$1/.git" ] || die "$1 could not possibly be a git repo; $1/.git is not a dir" } cd ~git/repositories/a.git . ~git/post-receive-email &> /dev/null ( set -x checkgit ~git/a cd ~git/a checkgit . pwd git pull php ~git/a/scripts/generate_markdown_documentation.php ) 

Y obtengo el siguiente resultado de git push:

 + checkgit /var/git/a + '[' -d /var/git/a/.git ']' + cd /var/git/a + checkgit . + '[' -d ./.git ']' + pwd /var/git/a + git pull fatal: Not a git repository: '.' + php /var/git/a/scripts/generate_markdown_documentation.php 

¿Más ayuda?

Ah, y si ejecuto el script yo mismo, funciona (lo ejecuto diciendo hooks / post-receive)

Descubrió el problema, gracias a la falla del server : básicamente, las variables de entorno GIT_DIR y GIT_WORK_TREE se configuran cuando se ejecuta el gancho, y esto afecta negativamente a git pull. Desarreglar las variables corrige el problema.

Necesita más diagnósticos, por ejemplo,

 function die { echo "$*" >&2; exit 1 } function checkgit { [ -d "$1/.git" ] || die "$1 could not possibly be a git repo; $1/.git is not a dir" } 

En este punto, en la subshell justo después del paréntesis, puedes probar cosas como

 set -x # show exactly what's executed (writes to stderr) checkgit ~git/a cd ~git/a && checkgit . && git pull ... 

También podría considerar networkingirigir la estructura completa de la subcadena, por ejemplo,

 ( ... ) 2>/tmp/mydiagnosis$$.log 

(Esta es una medida temporal y está bien solo si no hay información confidencial en los loggings).


OK Silas, tu información adicional descarta muchas posibilidades incómodas. Estoy llegando al final de mi git fu, pero aquí hay algunas cosas más que probar:

  1. Entra en ~git/a y mira si puedes hacer que git pull con la mano. Esto debería fallar
  2. Me metí en ~git/a y git status . Esto también debería fallar. Si no es así, entonces git está dando un post de error muy malo.

Si ambos pasos fallan, ~git/a no es el clon que creías que era. Cambie el nombre, cree un nuevo clon y vea si puede lograr que el problema persista.

Si el primer paso tiene éxito a mano, entonces algo extraño está sucediendo y estoy desconcertado.

Si el primer paso falla pero el segundo tiene éxito, puede tener un problema con las twigs:

  • Quizás el repository está configurado en la twig incorrecta, y su repository necesita una twig que no tiene. Pruebe git branch -a y vea si ve algo inesperado.

  • Tal vez tenga la sucursal, pero no está debidamente asociada con un repository remoto. En este punto, debes sumergirte en ~git/a/.git/config , y realmente no sé cómo explicar lo que debes esperar encontrar allí. En ese momento, necesitarás un verdadero experto en git; Solo toco uno en la televisión.

Recientemente me encontré con un problema similar y creo que está relacionado con las variables de entorno que establece git, específicamente la variable $ GIT_DIR. Si tiene ese set, todos los commands de git en otros repos comienzan a actuar de manera extraña. Básicamente, creo que ejecutar tu git pull dentro del gancho debe invocarse en un entorno de caparazón neutral que no tenga esas variables impares y conduzca a la confusión de git, aunque todavía no he descubierto cómo hacerlo.

unset GIT_DIR es una solución que funciona para el error fatal que estás viendo.

Esto se aplica a todas las secuencias de commands en los ganchos (la actualización posterior es otra común), que utiliza el command git dentro de ella. El command git usa GIT_DIR desde env en lugar de pwd.

Consulte http://sofes.miximages.com/a/4100577 para get más información.