Git Post-Receive-Hook funktioniert nicht

Wir verwenden Git mit einem zentralen Repo (mit Gitosis). Ich habe einen Post-Receive-Hook erstellt, um eine E-Mail an die Dev-Mailingliste zu generieren, wenn Änderungen an das zentrale Repo gesendet werden, und um Dokumentation aus dem Dokumentationsordner im Git-Repo zu generieren.

Daher habe ich in ~git/ ein Verzeichnis, wir nennen es ‘a’, das einen Klon des Git-Repos enthält. Der Post-Receive-Hook sieht so aus:

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

Das E-Mail-Skript funktioniert, aber die Dokumentationsgenerierung nicht. Der Inhalt von pull_log.log ist:

fatal: Not a git repository: '.'

Was mich denken lässt, dass es in Zeile 5 des obigen Skripts nicht in das richtige Verzeichnis wechselt. Liege ich falsch? Wie kann ich das zum Laufen bringen?

Bearbeiten: Ich habe den Post-Receive-Hook aktualisiert, wie in den Antworten vorgeschlagen. Das Skript lautet jetzt:

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

Und ich bekomme die folgende Ausgabe von 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

Noch mehr Hilfe?

Oh, und wenn ich das Skript selbst ausführe, funktioniert es (ich führe es aus, indem ich hooks/post-receive sage)

Habe das Problem entdeckt, dank Serverfehler — im Grunde Umgebungsvariablen GIT_DIR und GIT_WORK_TREE werden gesetzt, wenn der Hook läuft, und diese wirken sich negativ auf Git-Pull aus. Das Zurücksetzen der Variablen behebt das Problem.

Sie benötigen mehr Diagnostik, z.

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

An diesem Punkt, in der Subshell direkt nach der Klammer, können Sie Dinge wie versuchen

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

Sie könnten auch in Betracht ziehen, die gesamte Stderr der Subshell umzuleiten, z.

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

(Dies ist eine vorübergehende Maßnahme und nur in Ordnung, wenn die Protokolle keine vertraulichen Informationen enthalten.)

OK Silas, deine zusätzlichen Informationen schließen viele unangenehme Möglichkeiten aus. Ich nähere mich dem Ende meiner git fu, aber hier sind noch ein paar Dinge, die du ausprobieren kannst:

1. Gehen in ~git/a und schau ob du es schaffst git pull von Hand. Dies sollte fehlschlagen.
2. Hineingeraten ~git/a und Renn git status. Auch dies sollte scheitern. Wenn nicht, dann git gibt Ihnen eine sehr schlechte Fehlermeldung.

Wenn beide Schritte fehlschlagen, ~git/a ist nicht der Klon, für den Sie ihn gehalten haben. Benennen Sie es um, erstellen Sie einen neuen Klon und prüfen Sie, ob das Problem weiterhin besteht.

Gelingt der erste Schritt von Hand, dann geht etwas Seltsames vor und ich bin ratlos.

Wenn der erste Schritt fehlschlägt, der zweite jedoch erfolgreich ist, haben Sie möglicherweise ein Problem mit Zweigen:

• Vielleicht Repo ~git/a auf den falschen Branch gesetzt ist und Ihr Repo einen Branch benötigt, den es nicht hat. Versuchen git branch -a und sehen Sie, ob Sie etwas Unerwartetes sehen.

• Vielleicht haben Sie den Zweig, aber er ist nicht richtig mit einem entfernten Repository verknüpft. An dieser Stelle muss man eintauchen ~git/a/.git/config, und ich weiß nicht wirklich, wie ich erklären soll, was Sie dort erwarten sollten. An diesem Punkt benötigen Sie eine Real Git-Experte; Ich spiele nur einen im Fernsehen.

Ich bin kürzlich auf ein ähnliches Problem gestoßen, und ich denke, es hängt mit den Umgebungsvariablen zusammen, die git setzt, insbesondere mit der Variablen $GIT_DIR. Wenn Sie diesen Satz haben, fangen alle Git-Befehle auf anderen Repos an, sich seltsam zu verhalten. Grundsätzlich denke ich, dass das Ausführen Ihres Git-Pulls innerhalb des Hooks in einer neutralen Shell-Umgebung aufgerufen werden muss, die diese seltsamen Variablen nicht hat und zu Git-Verwirrung führt, obwohl ich noch nicht herausgefunden habe, wie das geht.

unset GIT_DIR ist eine Lösung, die für den schwerwiegenden Fehler, den Sie sehen, funktioniert.

Dies gilt für alle Skripte in Hooks (Post-Update ist ein weiteres gängiges), die den darin enthaltenen git-Befehl verwenden. git-Befehl verwendet das GIT_DIR von env anstelle von pwd.

Weitere Erläuterungen finden Sie unter https://stackoverflow.com/a/4100577.