Git post-ricezione gancio non funzionante

Question

Stiamo usando git con un repo centrale (usando Gitosis). Ho creato un post-ricezione gancio per generare una e-mail alla mailing list dev ogni volta che le modifiche sono spinti al repo centrale, e per generare la documentazione dalla cartella di documentazione nella repo git.

Pertanto, in ~ git / Ho una directory, che chiameremo 'a' che contiene un clone del repository git. Il post-ricezione gancio si presenta come:

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

Lo script di posta elettronica è in funzione, ma la generazione di documentazione non è. Il contenuto di pull_log.log è:

fatal: Not a git repository: '.'

Il che mi fa pensare che non sta cambiando nella directory corretta in linea 5 dello script di cui sopra. Ho sbagliato? Come posso ottenere questo lavoro?

Modifica Ho aggiornato il post-ricezione gancio come suggerito nelle risposte. Lo script è ora:

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

E ottengo il seguente output di 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

Non più di aiuto?

Oh, e se faccio funzionare lo scritto io stesso, funziona (l'eseguo dicendo ganci / post-ricezione)

Scoperto il problema, grazie a serverfault - in pratica, le variabili di ambiente e GIT_DIR GIT_WORK_TREE vengono impostati quando viene eseguito il gancio, e questi influenzano negativamente git pull. Disinserimento del variabili risolve il problema.

Answer 1

Hai bisogno di più la diagnostica, per es.,

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"
}

A questo punto, nella subshell subito dopo la parentesi, si può provare cose come

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

Si potrebbe anche considerare riorientare l'intera stderr del subshell, per es.,

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

(Si tratta di una misura temporanea ed è solo nella norma se non c'è informazioni confidenziali nei log.)

---

OK Silas, il vostro informazioni aggiuntive esclude un sacco di possibilità scomode. Sono quasi alla fine del mio git fu, ma qui ci sono alcune altre cose da provare:

1. Andate in ~git/a e vedere se si può fare git pull a mano. Questo dovrebbe fallire.
2. Il tutto in una ~git/a ed eseguire git status. Questo dovrebbe anche fallire. Se non lo fa, allora git ti dà un messaggio di errore molto male.

Se entrambi i passaggi non riescono, ~git/a non è il clone si pensava che fosse. Rinominarlo, fare un nuovo clone, e vedere se è possibile ottenere il problema persista.

Se il primo passo riesce a mano, poi qualcosa di strano sta succedendo e io sono sconcertato.

Se il primo passaggio non riesce, ma il secondo ha successo, si può avere un problema con rami:

• Forse repo ~git/a è impostato al ramo sbagliato, e il vostro repo ha bisogno di un ramo che non ha. Prova git branch -a e vedere se si vede qualcosa di inaspettato.

• Forse avete il ramo, ma non è correttamente legato al un repository remoto. A questo punto è necessario immergersi in ~git/a/.git/config, e io non so davvero come spiegare ciò che si dovrebbe aspettare di trovare lì. A quel punto avrete bisogno di un reale git esperto; Per giocare e basta uno in TV.

Answer 2

Di recente ho incontrato un problema simile e penso che è legato alle variabili di ambiente che Git set, in particolare la variabile $ GIT_DIR. Se si dispone di quel set, tutti i comandi Git su altri repos iniziare ad agire stranamente. Fondamentalmente penso che esegue il tiro git all'interno del gancio deve essere richiamato in un ambiente di shell neutro che non ha quei variabili dispari e porta a git confusione, anche se non ho capito come fare appena ancora.

Answer 3

unset GIT_DIR è una soluzione che funziona per l'errore fatale che state vedendo.

Questo vale per tutti gli script di ganci (post-aggiornamento è un altro comune uno), che utilizza il comando git suo interno. comando git utilizza il GIT_DIR da ENV invece di pwd.

Per ulteriori spiegazioni vedere https://stackoverflow.com/a/4100577 .