Dieser Hook wird von git-am[1] aufgerufen. Er erhält einen einzigen Parameter: den Namen der Datei, die die vorgeschlagene Commit-Log-Nachricht enthält. Wenn der Hook mit einem Status ungleich Null beendet wird, bricht git am ab, bevor der Patch angewendet wird.

Der Hook darf die Nachrichtendatei vor Ort bearbeiten und kann verwendet werden, um die Nachricht in ein Standardformat eines Projekts zu normalisieren. Er kann auch verwendet werden, um den Commit nach Überprüfung der Nachrichtendatei abzulehnen.

Der Standard-Hook applypatch-msg führt, wenn er aktiviert ist, den Hook commit-msg aus, falls letzterer aktiviert ist.

Dieser Hook wird von git-am[1] aufgerufen. Er erhält keine Parameter und wird aufgerufen, nachdem der Patch angewendet wurde, aber bevor ein Commit erstellt wird.

Wenn er mit einem Status ungleich Null beendet wird, wird der Arbeitsbaum nach dem Anwenden des Patches nicht committet.

Er kann verwendet werden, um den aktuellen Arbeitsbaum zu inspizieren und einen Commit abzulehnen, wenn er bestimmte Tests nicht besteht.

Der Standard-Hook pre-applypatch führt, wenn er aktiviert ist, den Hook pre-commit aus, falls letzterer aktiviert ist.

Dieser Hook wird von git-am[1] aufgerufen. Er erhält keine Parameter und wird aufgerufen, nachdem der Patch angewendet und ein Commit erstellt wurde.

Dieser Hook ist hauptsächlich für Benachrichtigungen gedacht und kann das Ergebnis von git am nicht beeinflussen.

Dieser Hook wird von git-commit[1] aufgerufen und kann mit der Option --no-verify umgangen werden. Er erhält keine Parameter und wird aufgerufen, bevor die vorgeschlagene Commit-Log-Nachricht abgerufen und ein Commit erstellt wird. Wenn dieses Skript mit einem Status ungleich Null beendet wird, bricht der Befehl git commit ab, bevor ein Commit erstellt wird.

Der Standard-Hook pre-commit fängt, wenn er aktiviert ist, die Einführung von Zeilen mit nachfolgenden Leerzeichen ab und bricht den Commit ab, wenn eine solche Zeile gefunden wird.

Alle git commit-Hooks werden mit der Umgebungsvariable GIT_EDITOR=: aufgerufen, wenn der Befehl keinen Editor zum Ändern der Commit-Nachricht aufruft.

Der Standard-Hook pre-commit verhindert, wenn er aktiviert ist – und mit der Konfigurationsoption hooks.allownonascii nicht gesetzt oder auf false gesetzt – die Verwendung von Dateinamen, die keine ASCII-Zeichen enthalten.

Dieser Hook wird von git-merge[1] aufgerufen und kann mit der Option --no-verify umgangen werden. Er erhält keine Parameter und wird aufgerufen, nachdem der Merge erfolgreich durchgeführt wurde und bevor die vorgeschlagene Commit-Log-Nachricht abgerufen wird, um einen Commit zu erstellen. Wenn dieses Skript mit einem Status ungleich Null beendet wird, bricht der Befehl git merge ab, bevor ein Commit erstellt wird.

Der Standard-Hook pre-merge-commit führt, wenn er aktiviert ist, den Hook pre-commit aus, falls letzterer aktiviert ist.

Dieser Hook wird mit der Umgebungsvariable GIT_EDITOR=: aufgerufen, wenn der Befehl keinen Editor zum Ändern der Commit-Nachricht aufruft.

Wenn der Merge nicht automatisch durchgeführt werden kann, müssen die Konflikte gelöst und das Ergebnis separat committet werden (siehe git-merge[1]). Zu diesem Zeitpunkt wird dieser Hook nicht ausgeführt, aber der Hook pre-commit wird ausgeführt, falls er aktiviert ist.

Dieser Hook wird von git-commit[1] aufgerufen, unmittelbar nachdem die Standard-Log-Nachricht vorbereitet wurde und bevor der Editor gestartet wird.

Er erhält ein bis drei Parameter. Der erste ist der Name der Datei, die die Commit-Log-Nachricht enthält. Der zweite ist die Quelle der Commit-Nachricht und kann sein: message (wenn eine Option -m oder -F angegeben wurde); template (wenn eine Option -t angegeben wurde oder die Konfigurationsoption commit.template gesetzt ist); merge (wenn der Commit ein Merge ist oder eine Datei .git/MERGE_MSG existiert); squash (wenn eine Datei .git/SQUASH_MSG existiert); oder commit, gefolgt von einem Commit-Objektnamen (wenn eine Option -c, -C oder --amend angegeben wurde).

Wenn der Exit-Status ungleich Null ist, bricht git commit ab.

Der Zweck des Hooks ist es, die Nachrichtendatei vor Ort zu bearbeiten, und er wird nicht durch die Option --no-verify unterdrückt. Ein Nicht-Null-Exit bedeutet einen Fehler des Hooks und bricht den Commit ab. Er sollte nicht als Ersatz für den pre-commit-Hook verwendet werden.

Der Beispiel-Hook prepare-commit-msg, der mit Git geliefert wird, entfernt die Hilfenachricht im kommentierten Teil der Commit-Vorlage.

Dieser Hook wird von git-commit[1] und git-merge[1] aufgerufen und kann mit der Option --no-verify umgangen werden. Er erhält einen einzigen Parameter: den Namen der Datei, die die vorgeschlagene Commit-Log-Nachricht enthält. Wenn er mit einem Status ungleich Null beendet wird, bricht der Befehl ab.

Der Hook darf die Nachrichtendatei vor Ort bearbeiten und kann verwendet werden, um die Nachricht in ein Standardformat eines Projekts zu normalisieren. Er kann auch verwendet werden, um den Commit nach Überprüfung der Nachrichtendatei abzulehnen.

Der Standard-Hook commit-msg erkennt, wenn er aktiviert ist, doppelte Signed-off-by-Trailer und bricht den Commit ab, wenn einer gefunden wird.

Dieser Hook wird von git-commit[1] aufgerufen. Er erhält keine Parameter und wird nach der Erstellung eines Commits aufgerufen.

Dieser Hook ist hauptsächlich für Benachrichtigungen gedacht und kann das Ergebnis von git commit nicht beeinflussen.

Dieser Hook wird von git-rebase[1] aufgerufen und kann verwendet werden, um zu verhindern, dass ein Branch rebased wird. Der Hook kann mit einem oder zwei Parametern aufgerufen werden. Der erste Parameter ist der Upstream, von dem die Serie verzweigt wurde. Der zweite Parameter ist der Branch, der rebased wird, und ist nicht gesetzt, wenn der aktuelle Branch rebased wird.

Dieser Hook wird aufgerufen, wenn ein git-checkout[1] oder git-switch[1] ausgeführt wird, nachdem der Arbeitsbaum aktualisiert wurde. Der Hook erhält drei Parameter: den Ref des vorherigen HEAD, den Ref des neuen HEAD (der sich möglicherweise geändert hat oder auch nicht) und ein Flag, das angibt, ob der Checkout ein Branch-Checkout war (Änderung von Branches, Flag=1) oder ein Datei-Checkout (Abrufen einer Datei aus dem Index, Flag=0). Dieser Hook kann das Ergebnis von git switch oder git checkout nicht beeinflussen, abgesehen davon, dass der Exit-Status des Hooks zum Exit-Status dieser beiden Befehle wird.

Er wird auch nach git-clone[1] ausgeführt, es sei denn, die Option --no-checkout (-n) wird verwendet. Der erste an den Hook übergebene Parameter ist der Null-Ref, der zweite der Ref des neuen HEAD und das Flag ist immer 1. Dasselbe gilt für git worktree add, es sei denn, --no-checkout wird verwendet.

Dieser Hook kann verwendet werden, um die Gültigkeit des Repositorys zu überprüfen, Unterschiede zum vorherigen HEAD automatisch anzuzeigen, wenn diese unterschiedlich sind, oder Metadaten-Eigenschaften des Arbeitsverzeichnisses festzulegen.

Dieser Hook wird von git-merge[1] aufgerufen, was passiert, wenn ein git pull in einem lokalen Repository ausgeführt wird. Der Hook erhält einen einzigen Parameter, ein Statusflag, das angibt, ob der durchgeführte Merge ein Squash-Merge war oder nicht. Dieser Hook kann das Ergebnis von git merge nicht beeinflussen und wird nicht ausgeführt, wenn der Merge aufgrund von Konflikten fehlschlägt.

Dieser Hook kann in Verbindung mit einem entsprechenden pre-commit Hook verwendet werden, um beliebige Metadaten, die mit dem Arbeitsbaum verbunden sind, zu speichern und wiederherzustellen (z. B. Berechtigungen/Besitz, ACLs usw.). Siehe contrib/hooks/setgitperms.perl für ein Beispiel, wie dies gemacht werden kann.

Dieser Hook wird von git-push[1] aufgerufen und kann verwendet werden, um einen Push zu verhindern. Der Hook wird mit zwei Parametern aufgerufen, die den Namen und den Speicherort des Ziel-Remotes angeben. Wenn kein benanntes Remote verwendet wird, sind beide Werte gleich.

Informationen darüber, was gepusht werden soll, werden über die Standardeingabe des Hooks in Zeilen der Form

Zum Beispiel, wenn der Befehl git push origin master:foreign ausgeführt würde, würde der Hook eine Zeile wie die folgende erhalten:

obwohl der vollständige Objektname bereitgestellt würde. Wenn das fremde Ref noch nicht existiert, ist <remote-object-name> der Null-Objektname. Wenn ein Ref gelöscht werden soll, wird <local-ref> als (delete) übergeben und <local-object-name> ist der Null-Objektname. Wenn der lokale Commit durch etwas anderes als einen Namen angegeben wurde, der erweitert werden konnte (wie z. B. HEAD~ oder ein Objektname), wird er so übergeben, wie er ursprünglich gegeben wurde.

Wenn dieser Hook mit einem Status ungleich Null beendet wird, bricht git push ab, ohne etwas zu pushen. Informationen darüber, warum der Push abgelehnt wird, können dem Benutzer durch Schreiben auf die Standardfehlerausgabe mitgeteilt werden.

Dieser Hook wird von git-receive-pack[1] aufgerufen, wenn dieser auf git push reagiert und Referenzen in seinem Repository aktualisiert. Kurz bevor die Aktualisierung der Refs im Remote-Repository beginnt, wird der pre-receive Hook aufgerufen. Sein Exit-Status bestimmt den Erfolg oder Misserfolg der Aktualisierung.

Dieser Hook wird einmal für den Empfangsvorgang ausgeführt. Er erhält keine Argumente, empfängt aber für jede zu aktualisierende Ref auf der Standardeingabe eine Zeile im Format

wobei <old-oid> der alte Objektname ist, der in der Ref gespeichert ist, <new-oid> der neue Objektname ist, der in der Ref gespeichert werden soll, und <ref-name> der vollständige Name der Ref ist. Beim Erstellen einer neuen Ref ist <old-oid> der Null-Objektname.

Wenn der Hook mit einem Status ungleich Null beendet wird, werden keine Refs aktualisiert. Wenn der Hook mit Null beendet wird, kann die Aktualisierung einzelner Refs durch den update Hook verhindert werden.

Sowohl die Standardausgabe als auch die Standardfehlerausgabe werden an git send-pack auf der anderen Seite weitergeleitet, sodass Sie einfach Meldungen für den Benutzer echo-en können.

Die Anzahl der auf der Kommandozeile von git push --push-option=... angegebenen Push-Optionen kann aus der Umgebungsvariable GIT_PUSH_OPTION_COUNT gelesen werden, und die Optionen selbst finden sich in GIT_PUSH_OPTION_0, GIT_PUSH_OPTION_1,.... Wenn ausgehandelt wird, die Push-Optionsphase nicht zu verwenden, werden die Umgebungsvariablen nicht gesetzt. Wenn der Client Push-Optionen auswählt, aber keine sendet, wird die Zählervariable auf Null gesetzt, GIT_PUSH_OPTION_COUNT=0.

Siehe den Abschnitt "Quarantine Environment" in git-receive-pack[1] für einige Hinweise.

Dieser Hook wird von git-receive-pack[1] aufgerufen, wenn dieser auf git push reagiert und Referenzen in seinem Repository aktualisiert. Kurz bevor die Ref im Remote-Repository aktualisiert wird, wird der update Hook aufgerufen. Sein Exit-Status bestimmt den Erfolg oder Misserfolg der Ref-Aktualisierung.

Der Hook wird einmal für jede zu aktualisierende Ref ausgeführt und erhält drei Parameter:

Ein Null-Exit des update Hooks erlaubt die Aktualisierung der Ref. Ein Exit mit einem Status ungleich Null verhindert, dass git receive-pack diese Ref aktualisiert.

Dieser Hook kann verwendet werden, um eine *erzwungene* Aktualisierung bestimmter Refs zu verhindern, indem sichergestellt wird, dass der Objektname ein Commit-Objekt ist, das ein Nachkomme des durch den alten Objektnamen benannten Commit-Objekts ist. Das heißt, um eine "nur Fast-Forward"-Richtlinie zu erzwingen.

Er könnte auch verwendet werden, um den alten..neuen Status zu protokollieren. Allerdings kennt er nicht die gesamte Menge an Branches, so dass er bei naiver Verwendung eine E-Mail pro Ref auslösen würde. Der post-receive Hook ist dafür besser geeignet.

In einer Umgebung, die den Zugriff der Benutzer nur auf Git-Befehle über das Netzwerk beschränkt, kann dieser Hook verwendet werden, um Zugriffskontrolle zu implementieren, ohne sich auf Dateisystembesitz und Gruppenmitgliedschaft zu verlassen. Siehe git-shell[1], wie Sie die Login-Shell verwenden können, um den Zugriff des Benutzers nur auf Git-Befehle zu beschränken.

Sowohl die Standardausgabe als auch die Standardfehlerausgabe werden an git send-pack auf der anderen Seite weitergeleitet, sodass Sie einfach Meldungen für den Benutzer echo-en können.

Der Standard-Hook update verhindert, wenn er aktiviert ist – und mit der Konfigurationsoption hooks.allowunannotated nicht gesetzt oder auf false gesetzt – das Pushen von unkommentierten Tags.

Dieser Hook wird von git-receive-pack[1] aufgerufen. Wenn der Server die mehrwertige Konfigurationsvariable receive.procReceiveRefs gesetzt hat und die an receive-pack gesendeten Befehle übereinstimmende Referenznamen haben, werden diese Befehle von diesem Hook ausgeführt, anstatt von der internen Funktion execute_commands(). Dieser Hook ist verantwortlich für die Aktualisierung der relevanten Referenzen und die Berichterstattung der Ergebnisse an receive-pack.

Dieser Hook wird einmal für den Empfangsvorgang ausgeführt. Er erhält keine Argumente, verwendet aber ein Pkt-Line-Protokoll, um mit receive-pack zu kommunizieren, um Befehle, Push-Optionen zu lesen und Ergebnisse zu senden. Im folgenden Beispiel für das Protokoll steht der Buchstabe S für receive-pack und der Buchstabe H für diesen Hook.

Jeder Befehl für den proc-receive Hook kann auf eine Pseudo-Referenz verweisen und hat immer einen Null-Old-Wert als seinen old-oid, während der proc-receive Hook eine alternative Referenz aktualisieren kann und die alternative Referenz bereits mit einem Nicht-Null-Old-oid existieren kann. In diesem Fall verwendet dieser Hook "option"-Direktiven, um erweiterte Attribute für die durch die führende "ok"-Direktive angegebene Referenz zu melden.

Die Berichterstattung der Befehle dieses Hooks sollte in der gleichen Reihenfolge erfolgen wie die Eingabe. Der Exit-Status des proc-receive Hooks bestimmt nur den Erfolg oder Misserfolg der ihm gesendeten Befehlsgruppe, es sei denn, ein atomarer Push wird verwendet.

Dieser Hook wird von git-receive-pack[1] aufgerufen, wenn dieser auf git push reagiert und Referenzen in seinem Repository aktualisiert. Der Hook wird im Remote-Repository einmal ausgeführt, nachdem alle vorgeschlagenen Ref-Aktualisierungen verarbeitet wurden und wenn mindestens eine Ref als Ergebnis aktualisiert wurde.

Der Hook erhält keine Argumente. Er empfängt für jede erfolgreich aktualisierte Ref eine Zeile auf der Standardeingabe im gleichen Format wie der pre-receive Hook.

Dieser Hook hat keinen Einfluss auf das Ergebnis von git receive-pack, da er nach Abschluss der eigentlichen Arbeit aufgerufen wird.

Dies ersetzt den post-update Hook, da er sowohl alte als auch neue Werte aller Refs zusätzlich zu ihren Namen erhält.

Sowohl die Standardausgabe als auch die Standardfehlerausgabe werden an git send-pack auf der anderen Seite weitergeleitet, sodass Sie einfach Meldungen für den Benutzer echo-en können.

Der Standard-Hook post-receive ist leer, aber es gibt ein Beispielskript post-receive-email im Verzeichnis contrib/hooks der Git-Distribution, das das Senden von Commit-E-Mails implementiert.

Die Anzahl der auf der Kommandozeile von git push --push-option=... angegebenen Push-Optionen kann aus der Umgebungsvariable GIT_PUSH_OPTION_COUNT gelesen werden, und die Optionen selbst finden sich in GIT_PUSH_OPTION_0, GIT_PUSH_OPTION_1,.... Wenn ausgehandelt wird, die Push-Optionsphase nicht zu verwenden, werden die Umgebungsvariablen nicht gesetzt. Wenn der Client Push-Optionen auswählt, aber keine sendet, wird die Zählervariable auf Null gesetzt, GIT_PUSH_OPTION_COUNT=0.

Weitere Details finden Sie im Abschnitt "post-receive" in git-receive-pack[1].

Dieser Hook wird von git-receive-pack[1] aufgerufen, wenn dieser auf git push reagiert und Referenzen in seinem Repository aktualisiert. Er wird im Remote-Repository einmal ausgeführt, nachdem alle Refs aktualisiert wurden.

Er erhält eine variable Anzahl von Parametern, von denen jeder der Name einer tatsächlich aktualisierten Ref ist.

Dieser Hook ist hauptsächlich für Benachrichtigungen gedacht und kann das Ergebnis von git receive-pack nicht beeinflussen.

Der Hook post-update kann feststellen, welche Heads gepusht wurden, aber er kennt nicht ihre ursprünglichen und aktualisierten Werte, daher ist er schlecht geeignet, um alte..neue Protokolle zu erstellen. Der Hook post-receive erhält sowohl die ursprünglichen als auch die aktualisierten Werte der Refs. Sie sollten ihn stattdessen in Betracht ziehen, wenn Sie diese benötigen.

Wenn der Standard-Hook post-update aktiviert ist, führt er git update-server-info aus, um die von dummen Transports (z. B. HTTP) verwendeten Informationen auf dem neuesten Stand zu halten. Wenn Sie ein Git-Repository veröffentlichen, das über HTTP zugänglich ist, sollten Sie diesen Hook wahrscheinlich aktivieren.

Sowohl die Standardausgabe als auch die Standardfehlerausgabe werden an git send-pack auf der anderen Seite weitergeleitet, sodass Sie einfach Meldungen für den Benutzer echo-en können.

Dieser Hook wird von jedem Git-Befehl aufgerufen, der Referenzaktualisierungen durchführt. Er wird jedes Mal ausgeführt, wenn eine Referenztransaktion vorbereitet, committet oder abgebrochen wird, und kann daher mehrmals aufgerufen werden. Der Hook unterstützt auch symbolische Referenzaktualisierungen.

Der Hook erhält genau ein Argument, das den aktuellen Zustand der gegebenen Referenztransaktion angibt:

Für jede Referenzaktualisierung, die der Transaktion hinzugefügt wurde, erhält der Hook auf der Standardeingabe eine Zeile im Format

wobei <old-value> der alte Objektname ist, der in die Referenztransaktion übergeben wurde, <new-value> der neue Objektname ist, der in der Ref gespeichert werden soll, und <ref-name> der vollständige Name der Ref ist. Beim erzwungenen Aktualisieren der Referenz unabhängig von ihrem aktuellen Wert oder wenn die Referenz neu erstellt werden soll, ist <old-value> der Null-Objektname. Um diese Fälle zu unterscheiden, können Sie den aktuellen Wert von <ref-name> über git rev-parse inspizieren.

Für symbolische Referenzaktualisierungen können die Felder <old_value> und <new-value> Referenzen anstelle von Objekten bezeichnen. Eine Referenz wird mit einem ref:-Präfix bezeichnet, wie ref:<ref-target>.

Der Exit-Status des Hooks wird für alle Zustände außer dem "prepared"-Zustand ignoriert. Im "prepared"-Zustand führt ein Exit-Status ungleich Null dazu, dass die Transaktion abgebrochen wird. Der Hook wird in diesem Fall nicht mit dem "aborted"-Zustand aufgerufen.

Dieser Hook wird von git-receive-pack[1] aufgerufen, wenn dieser auf git push reagiert und Referenzen in seinem Repository aktualisiert, und wenn der Push versucht, den aktuell ausgecheckten Branch zu aktualisieren und die Konfigurationsvariable receive.denyCurrentBranch auf updateInstead gesetzt ist. Ein solcher Push wird standardmäßig verweigert, wenn der Arbeitsbaum und der Index des Remote-Repositorys Unterschiede zum aktuell ausgecheckten Commit aufweisen; wenn sowohl der Arbeitsbaum als auch der Index mit dem aktuellen Commit übereinstimmen, werden sie aktualisiert, um der neu gepushten Spitze des Branches zu entsprechen. Dieser Hook dient dazu, das Standardverhalten zu überschreiben.

Der Hook erhält den Commit, mit dem die Spitze des aktuellen Branches aktualisiert werden soll. Er kann mit einem Status ungleich Null beendet werden, um den Push abzulehnen (wenn er dies tut, darf er den Index oder den Arbeitsbaum nicht ändern). Oder er kann alle notwendigen Änderungen am Arbeitsbaum und am Index vornehmen, um sie in den gewünschten Zustand zu bringen, wenn die Spitze des aktuellen Branches auf den neuen Commit aktualisiert wird, und mit einem Null-Status beenden.

Zum Beispiel kann der Hook einfach git read-tree -u -m HEAD "$1" ausführen, um git fetch zu emulieren, der in umgekehrter Richtung mit git push ausgeführt wird, da die Zweibaum-Form von git read-tree -u -m im Wesentlichen dasselbe ist wie git switch oder git checkout, das Branches wechselt und gleichzeitig die lokalen Änderungen im Arbeitsbaum beibehält, die nicht mit dem Unterschied zwischen den Branches kollidieren.

Dieser Hook wird von git gc --auto (siehe git-gc[1]) aufgerufen. Er erhält keine Parameter, und wenn dieses Skript mit einem Status ungleich Null beendet wird, bricht git gc --auto ab.

Dieser Hook wird von Befehlen aufgerufen, die Commits umschreiben (git-commit[1], wenn mit --amend aufgerufen, und git-rebase[1]; jedoch rufen vollständige Verlaufs- (Neu-)Schreibwerkzeuge wie git-fast-import[1] oder git-filter-repo sie normalerweise nicht auf!). Sein erster Argument bezeichnet den Befehl, von dem er aufgerufen wurde: derzeit einer von amend oder rebase. Zukünftig können weitere befehlsabhängige Argumente übergeben werden.

Der Hook erhält eine Liste der umgeschriebenen Commits auf stdin im Format

Die extra-info ist wieder befehlsabhängig. Wenn sie leer ist, wird das vorhergehende Leerzeichen ebenfalls weggelassen. Derzeit werden von keinem Befehl extra-info übergeben.

Der Hook läuft immer nach dem automatischen Kopieren von Notizen (siehe "notes.rewrite.<command>" in git-config[1]) und hat daher Zugriff auf diese Notizen.

Die folgenden befehlspezifischen Kommentare gelten:

Dieser Hook wird von git-send-email[1] aufgerufen.

Er erhält die folgenden Kommandozeilenargumente. Sie sind: 1. der Name der Datei, die den Inhalt der zu sendenden E-Mail enthält. 2. der Name der Datei, die die SMTP-Header der E-Mail enthält.

Die SMTP-Header werden auf die gleiche Weise übergeben, wie sie an das Mail Transport Agent (MTA) des Benutzers übergeben werden. Tatsächlich ist die an das MTA des Benutzers übergebene E-Mail der Inhalt von $2 gefolgt vom Inhalt von $1.

Ein Beispiel für einige gängige Header ist unten gezeigt. Beachten Sie die Großschreibung und die mehrzeilige Tabulatorstruktur.

Wenn mit einem Status ungleich Null beendet wird, bricht git send-email ab, bevor E-Mails gesendet werden.

Die folgenden Umgebungsvariablen werden beim Ausführen des Hooks gesetzt.

Diese Variablen können beispielsweise zur Validierung von Patch-Serien verwendet werden.

Der Beispiel-Hook sendemail-validate, der mit Git geliefert wird, prüft, ob alle gesendeten Patches (außer dem Deckblatt) auf dem Standard-Branch des Upstream-Repositorys ohne Konflikte angewendet werden können. Es werden einige Platzhalter für zusätzliche Validierungsschritte hinterlassen, die nach dem Anwenden aller Patches einer bestimmten Serie durchgeführt werden sollen.

Dieser Hook wird aufgerufen, wenn die Konfigurationsoption core.fsmonitor auf .git/hooks/fsmonitor-watchman oder .git/hooks/fsmonitor-watchmanv2 gesetzt ist, je nach Version des zu verwendenden Hooks.

Version 1 erhält zwei Argumente: eine Versionsnummer (1) und die Zeit in Nanosekunden seit Mitternacht des 1. Januar 1970.

Version 2 erhält zwei Argumente: eine Versionsnummer (2) und ein Token, das zur Identifizierung von Änderungen seit dem Token verwendet wird. Für Watchman wäre dies eine Uhr-ID. Diese Version muss das neue Token gefolgt von einem NUL vor der Liste der Dateien auf stdout ausgeben.

Der Hook sollte die Liste aller Dateien im Arbeitsverzeichnis auf stdout ausgeben, die sich seit der angeforderten Zeit geändert haben könnten. Die Logik sollte inklusiv sein, sodass keine potenziellen Änderungen übersehen werden. Die Pfade sollten relativ zum Stammverzeichnis des Arbeitsverzeichnisses sein und durch ein einzelnes NUL getrennt werden.

Es ist in Ordnung, Dateien einzuschließen, die sich nicht tatsächlich geändert haben. Alle Änderungen, einschließlich neu erstellter und gelöschter Dateien, sollten enthalten sein. Wenn Dateien umbenannt werden, sollten sowohl der alte als auch der neue Name enthalten sein.

Git wird einschränken, welche Dateien auf Änderungen überprüft werden und welche Verzeichnisse auf nicht verfolgte Dateien basierend auf den angegebenen Pfadnamen überprüft werden.

Eine optimierte Möglichkeit, Git mitzuteilen, dass "alle Dateien geändert wurden", ist die Rückgabe des Dateinamens /.

Der Exit-Status bestimmt, ob Git die Daten vom Hook zur Einschränkung seiner Suche verwendet. Im Fehlerfall fällt es auf die Überprüfung aller Dateien und Ordner zurück.

Dieser Hook wird von git-p4 submit aufgerufen.

Der Hook p4-changelist wird ausgeführt, nachdem die Changelist-Nachricht vom Benutzer bearbeitet wurde. Er kann mit der Option --no-verify umgangen werden. Er nimmt einen einzelnen Parameter entgegen, den Namen der Datei, die den vorgeschlagenen Changelist-Text enthält. Ein Abbruch mit einem Status ungleich Null führt zum Abbruch des Befehls.

Der Hook darf die Changelist-Datei bearbeiten und kann verwendet werden, um den Text in ein bestimmtes Projektstandardformat zu normalisieren. Er kann auch verwendet werden, um den Submit nach der Überprüfung der Nachrichtendatei zu verweigern.

Führen Sie git-p4 submit --help für Details aus.

Dieser Hook wird von git-p4 submit aufgerufen.

Der Hook p4-prepare-changelist wird direkt nach der Vorbereitung der Standard-Changelist-Nachricht und vor dem Starten des Editors ausgeführt. Er nimmt einen Parameter entgegen, den Namen der Datei, die den Changelist-Text enthält. Ein Abbruch des Skripts mit einem Status ungleich Null bricht den Prozess ab.

Der Zweck des Hooks ist es, die Nachrichtendatei an Ort und Stelle zu bearbeiten, und er wird nicht durch die Option --no-verify unterdrückt. Dieser Hook wird auch dann aufgerufen, wenn --prepare-p4-only gesetzt ist.

Führen Sie git-p4 submit --help für Details aus.

Dieser Hook wird von git-p4 submit aufgerufen.

Der Hook p4-post-changelist wird aufgerufen, nachdem der Submit in P4 erfolgreich war. Er nimmt keine Parameter entgegen und ist hauptsächlich für Benachrichtigungen gedacht und kann das Ergebnis der git p4 submit-Aktion nicht beeinflussen.

Führen Sie git-p4 submit --help für Details aus.

Dieser Hook wird von git-p4 submit aufgerufen. Er nimmt keine Parameter und nichts von der Standardeingabe entgegen. Ein Abbruch dieses Skripts mit einem Status ungleich Null verhindert, dass git-p4 submit gestartet wird. Er kann mit der Kommandozeilenoption --no-verify umgangen werden. Führen Sie git-p4 submit --help für Details aus.

Dieser Hook wird aufgerufen, wenn der Index in read-cache.c do_write_locked_index geschrieben wird.

Der erste Parameter, der an den Hook übergeben wird, ist der Indikator für die Aktualisierung des Arbeitsverzeichnisses. "1" bedeutet, dass das Arbeitsverzeichnis aktualisiert wurde, oder "0", wenn das Arbeitsverzeichnis nicht aktualisiert wurde.

Der zweite an den Hook übergebene Parameter ist der Indikator dafür, ob der Index aktualisiert wurde und ob sich das skip-worktree-Bit geändert haben könnte. "1" bedeutet, dass sich skip-worktree-Bits möglicherweise geändert haben, und "0", dass dies nicht der Fall war.

Nur ein Parameter sollte auf "1" gesetzt sein, wenn der Hook ausgeführt wird. Das Ausführen des Hooks mit "1", "1" sollte nicht möglich sein.