Wenn Sie zu unserem geteilten blanken Repository (über ssh) drängen, funktioniert das Post-Commit nicht richtig.
Es ist ziemlich üblich, wie ich in vielen Threads hier herausgefunden habe und es funktioniert gut für zwei andere Repositories auf dem gleichen Server, was mich verrückt macht.
Das Repository selbst befindet sich im selben Verzeichnis wie das Verzeichnis, das der Hook an
auschecken soll %Vor%Beim Drücken werden die Dateien nicht auf den vorgesehenen Pfad ausgecheckt, sondern es wird folgende Fehlermeldung angezeigt:
%Vor%Ich konnte keine Informationen darüber finden, was das bedeutet. (Google bringt nur Commits von dem Beitrag zu git selbst, solange ich sagen kann). Also habe ich gelesen und erraten und versucht ...
Im Moment sieht die Konfiguration so aus
%Vor%aber ich hatte das auch (ohne Aufwand)
%Vor%Ich habe dem post-receive-Hook auch eine zweite Zeile hinzugefügt
%Vor%Es schreibt die Datei in das Verzeichnis des blanken Repositorys. Das macht für mich Sinn, da GIT_DIR auf '.' Gesetzt zu sein scheint, was durch ein Post-Receive-Snipped bestätigt wird, das ich von einer anderen SO-Frage bekommen habe.
%Vor%Ergebnis:
%Vor%Also, wie kann ich git bringen, um zurück zum ursprünglichen cwd (aktuelles Arbeitsverzeichnis?) zu springen? Zu Ihrer Information: Ich bin immer noch ziemlich neu in Sachen GIT und habe das dumme Gefühl, dass ich etwas Offensichtliches vermisse, aber nichts über diese spezielle Fehlermeldung zu erfahren lässt mich wundern. Der Push selbst funktioniert gut, übrigens.
Ich habe dieses Problem auch für eine von zehn Websites erfahren, die auf demselben Server gehostet wurden.
Jede Seite hat ein blankes Repo auf dem Webserver (nicht im Web verfügbar), auf den unsere Entwickler drängen. Wie Sie verwenden wir einen git post-receive-Hook, um dann GIT_WORK_TREE=/whatever/livesite git checkout -f in das Verzeichnis zu setzen, das den eigentlichen Webserver-Root enthält.
Untersuchen Sie, was anders war als der, der mit fatal: Could not jump back into original cwd fehlschlug. Ich sah, dass die Repository-Namen in allen Arbeitsfällen so aussahen:
Der eine Fehler war wie folgt:
%Vor%Wenn die live ausgecheckte Kopie einen Namen wie diesen hat, hat git diesen Fehler ausgelöst. Das Ändern des Namens des repo der Live-Site-Arbeitskopie, um mit '.wtf' zu enden, behob das Problem (ich habe schließlich nur '.live' wie die anderen verwendet).
In meinem Fall ist die Server-Version von Git 1.6.1, während die Dev-Maschinen alle 1.7.5.4 sind.
Der Name des bloßen Repos und des Live-Repo scheint also eine Rolle zu spielen. Nicht sicher, ob dies ein Fehler in Git oder nur eine Nebenwirkung von einigen der magischen Äquivalenz von "foo" und "foo.git" ist.
Aus meiner Erfahrung besteht Ihr Problem darin, dass Sie Ihr .git-Repository und Ihr Arbeitsverzeichnis (in dem Ihr Post-Receive-Hook ausgecheckt ist) im selben Verzeichnis haben: ab / cd.
Ich bin auch neu bei GIT, und dieser Beitrag hat mir sehr geholfen, danke! Nachdem ich alle Fixes beseitigt hatte, die Sie bereits versucht hatten, stolperte ich irgendwo über einen Post (ich fürchte, ich kann ihn jetzt nicht finden), der das .git-Repository gelesen hat, und das Arbeitsbaumverzeichnis kann nicht im selben Verzeichnis sein.
Ich weiß nicht warum.
Sie haben z. B. Ihr Verzeichnis / staging / in Ihrem Verzeichnis / var / www. Das würde bedeuten, dass Sie Ihr blankes .git-Repository in / var / GIT (oder etwas) ablegen sollten, nicht in / var / www.
Ein anderes Problem, das ich hatte, waren die Berechtigungen, also habe ich beide Verzeichnisse chmodiert und chmodiert, um sicherzustellen, dass der entfernte Benutzer, mit dem ich gedrängt hatte, Lese- und Schreibzugriff auf beide Verzeichnisse hatte.
Wie auch immer, ich habe das getan und ich kam von wo Sie waren:
%Vor%Das und ein schönes Fett Auschecken Verzeichnis voller Code:)
Tags und Links git git-post-receive