Dieses Attribut kennzeichnet den Pfad als Textdatei, was die Umwandlung von Zeilenenden ermöglicht: Wenn eine passende Datei zum Index hinzugefügt wird, werden die Zeilenenden der Datei im Index auf LF normalisiert. Umgekehrt, wenn die Datei vom Index in das Arbeitsverzeichnis kopiert wird, können ihre Zeilenenden je nach eol-Attribut, der Git-Konfiguration und der Plattform von LF in CRLF umgewandelt werden (siehe Erklärung von eol unten).

Jeder andere Wert führt dazu, dass Git sich so verhält, als wäre text nicht spezifiziert geblieben.

Dieses Attribut kennzeichnet einen Pfad zur Verwendung eines bestimmten Zeilenendungsstils im Arbeitsbaum, wenn er ausgecheckt wird. Es hat nur dann eine Auswirkung, wenn text oder text=auto gesetzt ist (siehe oben), aber die Angabe von eol setzt automatisch text, wenn text nicht spezifiziert war.

Aus Kompatibilitätsgründen wird das crlf-Attribut wie folgt interpretiert

Während Git normalerweise Dateiinhalte unverändert lässt, kann es konfiguriert werden, Zeilenenden im Repository auf LF zu normalisieren und optional bei Check-outs in CRLF umzuwandeln.

Wenn Sie einfach nur CRLF-Zeilenenden in Ihrem Arbeitsbaum haben möchten, unabhängig davon, mit welchem Repository Sie arbeiten, können Sie die Konfigurationsvariable "core.autocrlf" setzen, ohne Attribute zu verwenden.

Dies erzwingt keine Normalisierung von Textdateien, stellt aber sicher, dass Textdateien, die Sie in das Repository einführen, beim Hinzufügen normalisierte Zeilenenden auf LF haben und dass Dateien, die bereits im Repository normalisiert sind, normalisiert bleiben.

Wenn Sie sicherstellen möchten, dass Textdateien, die von beliebigen Mitwirkenden in das Repository eingeführt werden, normalisierte Zeilenenden haben, können Sie das text-Attribut für alle Dateien auf "auto" setzen.

Die Attribute ermöglichen eine feingranulare Kontrolle über die Konvertierung der Zeilenenden. Hier ist ein Beispiel, das Git veranlasst, .txt-, .vcproj- und .sh-Dateien zu normalisieren, sicherzustellen, dass .vcproj-Dateien im Arbeitsbaum CRLF und .sh-Dateien LF haben, und zu verhindern, dass .jpg-Dateien unabhängig von ihrem Inhalt normalisiert werden.

Aus einem sauberen Arbeitsbaum

Wenn Dateien, die nicht normalisiert werden sollten, in git status erscheinen, setzen Sie ihr text-Attribut auf "unset", bevor Sie git add -u ausführen.

Umgekehrt können Textdateien, die Git nicht erkennt, manuell für die Normalisierung aktiviert werden.

Wenn core.safecrlf auf "true" oder "warn" gesetzt ist, prüft Git, ob die Konvertierung für die aktuelle Einstellung von core.autocrlf umkehrbar ist. Bei "true" lehnt Git umkehrbare Konvertierungen ab; bei "warn" gibt Git nur eine Warnung aus, akzeptiert aber eine umkehrbare Konvertierung. Die Sicherheitsmechanismen verhindern solche Konvertierungen für Dateien im Arbeitsbaum, es gibt jedoch einige Ausnahmen. Auch wenn…

Git erkennt Dateien, die in ASCII oder einer seiner Obermengen (z. B. UTF-8, ISO-8859-1, …) kodiert sind, als Textdateien. Dateien, die in bestimmten anderen Kodierungen (z. B. UTF-16) kodiert sind, werden als Binärdateien interpretiert und folglich verarbeiten integrierte Git-Textverarbeitungswerkzeuge (z. B. git diff) sowie die meisten Git-Web-Frontends die Inhalte dieser Dateien standardmäßig nicht.

In diesen Fällen können Sie Git die Kodierung einer Datei im Arbeitsverzeichnis mit dem Attribut working-tree-encoding mitteilen. Wenn eine Datei mit diesem Attribut zu Git hinzugefügt wird, kodiert Git den Inhalt von der angegebenen Kodierung in UTF-8 um. Schließlich speichert Git den UTF-8-kodierten Inhalt in seiner internen Datenstruktur (genannt "Index"). Beim Check-out wird der Inhalt zurück in die angegebene Kodierung umkodiert.

Bitte beachten Sie, dass die Verwendung des Attributs working-tree-encoding eine Reihe von Fallstricken haben kann

Verwenden Sie das Attribut working-tree-encoding nur, wenn Sie eine Datei nicht in UTF-8-Kodierung speichern können und Git den Inhalt als Text verarbeiten können soll.

Verwenden Sie beispielsweise die folgenden Attribute, wenn Ihre *.ps1-Dateien UTF-16-kodiert mit Byte Order Mark (BOM) sind und Git die automatische Zeilenende-Konvertierung basierend auf Ihrer Plattform durchführen soll.

Verwenden Sie die folgenden Attribute, wenn Ihre *.ps1-Dateien UTF-16 Little Endian ohne BOM kodiert sind und Git Windows-Zeilenenden im Arbeitsbaum verwenden soll (verwenden Sie UTF-16LE-BOM anstelle von UTF-16LE, wenn Sie UTF-16 Little Endian mit BOM wünschen). Bitte beachten Sie, dass es dringend empfohlen wird, die Zeilenenden explizit mit eol zu definieren, wenn das Attribut working-tree-encoding verwendet wird, um Mehrdeutigkeiten zu vermeiden.

Sie können eine Liste aller auf Ihrer Plattform verfügbaren Kodierungen mit dem folgenden Befehl abrufen

Wenn Sie die Kodierung einer Datei nicht kennen, können Sie den Befehl file verwenden, um die Kodierung zu erraten

Wenn das Attribut ident für einen Pfad gesetzt ist, ersetzt Git beim Check-out $Id$ im Blob-Objekt durch $Id:, gefolgt vom 40-stelligen hexadezimalen Blob-Objektnamen, gefolgt von einem Dollarzeichen $. Jede Byte-Sequenz, die mit $Id: beginnt und mit $ in der Arbeitsbaumdatei endet, wird beim Check-in durch $Id$ ersetzt.

Ein filter-Attribut kann auf einen String-Wert gesetzt werden, der einen in der Konfiguration definierten Filtertreiber benennt.

Ein Filtertreiber besteht aus einem clean-Befehl und einem smudge-Befehl, wobei jeder davon optional sein kann. Beim Check-out wird, wenn der smudge-Befehl angegeben ist, der Befehl vom Standard-Input mit dem Blob-Objekt gespeist, und seine Standard-Ausgabe wird verwendet, um die Arbeitsbaumdatei zu aktualisieren. Ebenso wird der clean-Befehl verwendet, um die Inhalte der Arbeitsbaumdatei beim Check-in zu konvertieren. Standardmäßig verarbeiten diese Befehle nur einen einzelnen Blob und beenden sich. Wenn ein langlaufender process-Filter anstelle von clean und/oder smudge-Filtern verwendet wird, kann Git alle Blobs mit einer einzigen Filterbefehl-Invocation für die gesamte Lebensdauer eines einzelnen Git-Befehls verarbeiten, zum Beispiel git add --all. Wenn ein langlaufender process-Filter konfiguriert ist, hat er immer Vorrang vor einem konfigurierten Ein-Blob-Filter. Siehe den unten stehenden Abschnitt für die Beschreibung des Protokolls zur Kommunikation mit einem process-Filter.

Ein Anwendungsfall des Inhaltsfilters ist die Aufbereitung des Inhalts in eine Form, die für die Plattform, das Dateisystem und den Benutzer bequemer zu verwenden ist. Für diese Betriebsart ist die Schlüsselphrase hier "bequemer" und nicht "etwas Unbrauchbares in etwas Brauchbares verwandeln". Mit anderen Worten, die Absicht ist, dass das Projekt auch dann noch nutzbar sein sollte, wenn jemand die Filtertreiberdefinition aufhebt oder kein entsprechendes Filterprogramm hat.

Ein weiterer Anwendungsfall des Inhaltsfilters ist die Speicherung von Inhalten, die nicht direkt im Repository verwendet werden können (z. B. eine UUID, die auf den wahren Inhalt außerhalb von Git verweist, oder verschlüsselte Inhalte), und die Umwandlung in eine brauchbare Form beim Check-out (z. B. Herunterladen des externen Inhalts oder Entschlüsseln des verschlüsselten Inhalts).

Diese beiden Filter verhalten sich unterschiedlich, und standardmäßig wird ein Filter als erster betrachtet, der Inhalte in eine bequemere Form umwandelt. Eine fehlende Filtertreiberdefinition in der Konfiguration oder ein Filtertreiber, der mit einem Fehlerstatus ungleich Null beendet wird, ist kein Fehler, sondern macht den Filter zu einem passiven Passthrough.

Sie können deklarieren, dass ein Filter Inhalte, die an sich unbrauchbar sind, in brauchbare Inhalte umwandelt, indem Sie die Konfigurationsvariable filter.<driver>.required auf true setzen.

Hinweis: Jedes Mal, wenn der Clean-Filter geändert wird, sollte das Repository neu normalisiert werden: $ git add --renormalize .

Beispielsweise würden Sie in .gitattributes dem filter-Attribut für Pfade zuweisen.

Dann würden Sie in Ihrer .git/config oder $HOME/.gitconfig eine "filter.indent.clean"- und "filter.indent.smudge"-Konfiguration definieren, um ein Paar von Befehlen anzugeben, die die Inhalte von C-Programmen modifizieren, wenn die Quelldateien eingecheckt ("clean" wird ausgeführt) und ausgecheckt werden (es wird keine Änderung vorgenommen, da der Befehl "cat" ist).

Für beste Ergebnisse sollte clean seine Ausgabe nicht weiter verändern, wenn es zweimal ausgeführt wird ("clean→clean" sollte äquivalent zu "clean" sein), und mehrere smudge-Befehle sollten die Ausgabe von clean nicht verändern ("smudge→smudge→clean" sollte äquivalent zu "clean" sein). Siehe den Abschnitt über Merging unten.

Der "indent"-Filter verhält sich in dieser Hinsicht gut: Er verändert nicht die Eingabe, die bereits korrekt eingerückt ist. In diesem Fall bedeutet das Fehlen eines Smudge-Filters, dass der Clean-Filter seine eigene Ausgabe ohne Veränderung akzeptieren muss.

Wenn ein Filter erfolgreich sein muss, um die gespeicherten Inhalte nutzbar zu machen, können Sie deklarieren, dass der Filter in der Konfiguration erforderlich ist

Die Sequenz "%f" auf der Filter-Befehlszeile wird durch den Namen der Datei ersetzt, an der der Filter arbeitet. Ein Filter kann dies in der Keyword-Substitution verwenden. Zum Beispiel

Beachten Sie, dass "%f" der Name des Pfades ist, an dem gearbeitet wird. Abhängig von der Version, die gefiltert wird, existiert die entsprechende Datei auf der Festplatte möglicherweise nicht oder hat andere Inhalte. Daher sollten Smudge- und Clean-Befehle nicht auf die Datei auf der Festplatte zugreifen, sondern nur als Filter auf die ihnen über die Standardeingabe bereitgestellten Inhalte wirken.

Wenn der Filterbefehl (ein String-Wert) über filter.<driver>.process definiert wird, kann Git alle Blobs mit einer einzigen Filter-Invocation für die gesamte Lebensdauer eines einzelnen Git-Befehls verarbeiten. Dies wird durch die Verwendung des langlaufenden Prozessprotokolls erreicht (beschrieben in Documentation/technical/long-running-process-protocol.adoc).

Wenn Git auf die erste Datei stößt, die gereinigt oder verschmiert werden muss, startet es den Filter und führt den Handshake durch. Beim Handshake lautet die von Git gesendete Willkommensnachricht "git-filter-client", nur Version 2 wird unterstützt, und die unterstützten Fähigkeiten sind "clean", "smudge" und "delay".

Danach sendet Git eine Liste von "Schlüssel=Wert"-Paaren, die mit einem Flush-Paket abgeschlossen werden. Die Liste enthält mindestens den Filterbefehl (basierend auf den unterstützten Fähigkeiten) und den Pfadnamen der zu filternden Datei relativ zum Repository-Root. Direkt nach dem Flush-Paket sendet Git den Inhalt in null oder mehr pkt-line-Paketen und einem Flush-Paket zur Beendigung des Inhalts. Bitte beachten Sie, dass der Filter keine Antwort senden darf, bevor er den Inhalt und das abschließende Flush-Paket erhalten hat. Beachten Sie auch, dass der "Wert" eines "Schlüssel=Wert"-Paares das "=" Zeichen enthalten kann, während der Schlüssel dieses Zeichen niemals enthalten würde.

Der Filter wird erwartet, mit einer Liste von "Schlüssel=Wert"-Paaren zu antworten, die mit einem Flush-Paket abgeschlossen werden. Wenn der Filter keine Probleme hat, muss die Liste einen "success"-Status enthalten. Direkt nach diesen Paketen wird erwartet, dass der Filter den Inhalt in null oder mehr pkt-line-Paketen und einem abschließenden Flush-Paket sendet. Schließlich wird eine zweite Liste von "Schlüssel=Wert"-Paaren, die mit einem Flush-Paket abgeschlossen wird, erwartet. Der Filter kann den Status in der zweiten Liste ändern oder den Status unverändert lassen mit einer leeren Liste. Bitte beachten Sie, dass die leere Liste ungeachtet dessen mit einem Flush-Paket abgeschlossen werden muss.

Wenn der Ergebnisinhalt leer ist, wird erwartet, dass der Filter mit einem "success"-Status und einem Flush-Paket antwortet, um den leeren Inhalt zu signalisieren.

Wenn der Filter den Inhalt nicht verarbeiten kann oder will, wird erwartet, dass er mit einem "error"-Status antwortet.

Wenn der Filter während der Verarbeitung einen Fehler auftritt, kann er den Status "error" senden, nachdem der Inhalt (teilweise oder vollständig) gesendet wurde.

Wenn der Filter den Inhalt nicht verarbeiten kann oder will und auch zukünftige Inhalte für die Lebensdauer des Git-Prozesses nicht verarbeiten kann, wird erwartet, dass er zu jedem Zeitpunkt des Protokolls mit einem "abort"-Status antwortet.

Git stoppt oder startet den Filterprozess weder, wenn der Status "error" / "abort" gesetzt ist. Git setzt jedoch seinen Exit-Code entsprechend dem Flag filter.<driver>.required und ahmt damit das Verhalten des Mechanismus filter.<driver>.clean / filter.<driver>.smudge nach.

Wenn der Filter während der Kommunikation abstürzt oder das Protokoll nicht einhält, wird Git den Filterprozess stoppen und ihn mit der nächsten zu verarbeitenden Datei neu starten. Abhängig vom Flag filter.<driver>.required interpretiert Git dies als Fehler.

Wenn der Filter die "delay"-Fähigkeit unterstützt, kann Git nach dem Filterbefehl und Pfadnamen das Flag "can-delay" senden. Dieses Flag zeigt an, dass der Filter die Filterung des aktuellen Blobs verzögern kann (z. B. zur Kompensation von Netzwerk-Latenzen), indem er ohne Inhalt, aber mit dem Status "delayed" und einem Flush-Paket antwortet.

Wenn der Filter die "delay"-Fähigkeit unterstützt, muss er die Befehlsoption "list_available_blobs" unterstützen. Wenn Git diesen Befehl sendet, wird erwartet, dass der Filter eine Liste von Pfadnamen zurückgibt, die zuvor verzögerte Blobs repräsentieren und nun verfügbar sind. Die Liste muss mit einem Flush-Paket gefolgt von einem "success"-Status abgeschlossen werden, der ebenfalls mit einem Flush-Paket abgeschlossen wird. Wenn noch keine Blobs für die verzögerten Pfade verfügbar sind, wird erwartet, dass der Filter die Antwort blockiert, bis mindestens ein Blob verfügbar ist. Der Filter kann Git mitteilen, dass er keine weiteren verzögerten Blobs mehr hat, indem er eine leere Liste sendet. Sobald der Filter mit einer leeren Liste antwortet, hört Git auf zu fragen. Alle Blobs, die Git bis zu diesem Zeitpunkt nicht erhalten hat, gelten als fehlend und führen zu einem Fehler.

Nachdem Git die Pfadnamen erhalten hat, fordert es die entsprechenden Blobs erneut an. Diese Anfragen enthalten einen Pfadnamen und einen leeren Inhaltsabschnitt. Es wird erwartet, dass der Filter den verschmutzten Inhalt auf die übliche Weise wie oben beschrieben zurückgibt.

Eine Demoimplementierung eines langlaufenden Filters finden Sie in contrib/long-running-filter/example.pl im Git-Kern-Repository. Wenn Sie Ihren eigenen langlaufenden Filterprozess entwickeln, können die Umgebungsvariablen GIT_TRACE_PACKET sehr hilfreich für die Fehlersuche sein (siehe git[1]).

Bitte beachten Sie, dass Sie keinen vorhandenen Befehl filter.<driver>.clean oder filter.<driver>.smudge mit filter.<driver>.process verwenden können, da die beiden ersteren ein anderes Interprozesskommunikationsprotokoll als letzteres verwenden.

Im Check-in-Codepfad wird die Arbeitsbaumdatei zuerst mit dem filter-Treiber (falls spezifiziert und der entsprechende Treiber definiert) konvertiert, dann wird das Ergebnis mit ident (falls spezifiziert) und dann schließlich mit text (wiederum, falls spezifiziert und anwendbar) verarbeitet.

Im Check-out-Codepfad wird der Blob-Inhalt zuerst mit text, dann mit ident konvertiert und an filter weitergeleitet.

Wenn Sie einem Dateiatribut hinzugefügt haben, das das kanonische Repository-Format für diese Datei ändert, z. B. durch Hinzufügen eines Clean/Smudge-Filters oder Text/EOL/Ident-Attributen, würde das Zusammenführen von allem, wo das Attribut nicht vorhanden ist, normalerweise zu Merge-Konflikten führen.

Um diese unnötigen Merge-Konflikte zu verhindern, kann Git angewiesen werden, einen virtuellen Check-out und Check-in aller drei Stufen jeder Datei, die einen dreiseitigen Inhalts-Merge benötigt, auszuführen, indem die Konfigurationsvariable merge.renormalize gesetzt wird. Dies verhindert, dass durch die Check-in-Konvertierung verursachte Änderungen zu falschen Merge-Konflikten führen, wenn eine konvertierte Datei mit einer nicht konvertierten Datei zusammengeführt wird.

Solange ein "smudge→clean" dasselbe Ergebnis wie ein "clean" liefert, auch bei bereits "geschmierten" Dateien, löst diese Strategie automatisch alle filterbezogenen Konflikte. Filter, die sich nicht so verhalten, können zusätzliche Merge-Konflikte verursachen, die manuell gelöst werden müssen.

Das Attribut diff beeinflusst, wie Git Diffs für bestimmte Dateien generiert. Es kann Git mitteilen, ob ein textueller Patch für den Pfad generiert werden soll oder ob der Pfad als Binärdatei behandelt werden soll. Es kann auch beeinflussen, welche Zeile im Hunk-Header @@ -k,l +n,m @@ angezeigt wird, Git anweisen, einen externen Befehl zur Generierung des Diffs zu verwenden oder Git anweisen, Binärdateien vor der Generierung des Diffs in ein Textformat zu konvertieren.

Die Definition eines Diff-Treibers erfolgt in gitconfig, nicht in der gitattributes-Datei, daher ist diese Manualpage streng genommen der falsche Ort dafür. Aber…

Um einen externen Diff-Treiber jcdiff zu definieren, fügen Sie Ihrer Datei $GIT_DIR/config (oder $HOME/.gitconfig) einen Abschnitt wie diesen hinzu

Wenn Git Ihnen einen Diff für den Pfad mit dem Attribut diff, gesetzt auf jcdiff, anzeigen muss, ruft es den von Ihnen angegebenen Befehl mit der obigen Konfiguration auf, d. h. j-c-diff, mit 7 Parametern, genauso wie das Programm GIT_EXTERNAL_DIFF aufgerufen wird. Weitere Details finden Sie in git[1].

Wenn das Programm bestimmte Änderungen ignorieren kann (ähnlich wie git diff --ignore-space-change), dann setzen Sie auch die Option trustExitCode auf true. Es wird dann erwartet, dass es den Exit-Code 1 zurückgibt, wenn es signifikante Änderungen findet, und 0, wenn nicht.

Der Diff-Algorithmus kann über den Konfigurationsschlüssel diff.algorithm festgelegt werden, aber manchmal kann es hilfreich sein, den Diff-Algorithmus pro Pfad festzulegen. Man möchte zum Beispiel vielleicht den minimal Diff-Algorithmus für .json-Dateien und den histogram für .c-Dateien verwenden und so weiter, ohne den Algorithmus jedes Mal über die Kommandozeile übergeben zu müssen.

Zuerst wird in .gitattributes das Attribut diff für Pfade zugewiesen.

Anschließend wird eine Konfiguration "diff.<name>.algorithm" definiert, um den Diff-Algorithmus festzulegen, wählbar aus myers, patience, minimal oder histogram.

Dieser Diff-Algorithmus gilt für die für den Benutzer sichtbare Diff-Ausgabe wie git-diff(1), git-show(1) und wird auch für die --stat-Ausgabe verwendet. Die Merge-Mechanismen verwenden den auf diese Weise festgelegten Diff-Algorithmus nicht.

Jede Gruppe von Änderungen (genannt "Hunk") in der textuellen Diff-Ausgabe wird mit einer Zeile der Form vorangestellt

Dies wird als Hunk-Header bezeichnet. Der "TEXT"-Teil ist standardmäßig eine Zeile, die mit einem Buchstaben, einem Unterstrich oder einem Dollarzeichen beginnt; dies entspricht der Ausgabe von GNU diff -p. Diese Standardauswahl ist jedoch für einige Inhalte nicht geeignet, und Sie können ein benutzerdefiniertes Muster verwenden, um eine Auswahl zu treffen.

Zuerst wird in .gitattributes das Attribut diff für Pfade zugewiesen.

Dann definieren Sie eine Konfiguration "diff.tex.xfuncname", um einen regulären Ausdruck anzugeben, der auf eine Zeile passt, die Sie als "TEXT" des Hunk-Headers erscheinen lassen möchten. Fügen Sie Ihrem $GIT_DIR/config- oder $HOME/.gitconfig-Datei einen Abschnitt wie diesen hinzu

Hinweis. Eine einzelne Ebene von Backslashes wird vom Konfigurationsdateiparser verschluckt, sodass Sie die Backslashes verdoppeln müssen; das obige Muster wählt eine Zeile aus, die mit einem Backslash beginnt, und null oder mehr Vorkommen von sub gefolgt von section gefolgt von einer öffnenden Klammer bis zum Ende der Zeile.

Es gibt einige eingebaute Muster, die dies erleichtern, und tex ist eines davon, sodass Sie das oben Genannte nicht in Ihre Konfigurationsdatei schreiben müssen (Sie müssen dies immer noch über den Attributmechanismus mit .gitattributes aktivieren). Die folgenden eingebauten Muster sind verfügbar

Sie können die Regeln, die git diff --word-diff zum Aufteilen von Wörtern in einer Zeile verwendet, anpassen, indem Sie einen geeigneten regulären Ausdruck in der Konfigurationsvariable "diff.*.wordRegex" angeben. In TeX bildet beispielsweise ein Backslash gefolgt von einer Buchstabenfolge einen Befehl, aber mehrere solcher Befehle können ohne dazwischenliegende Leerzeichen hintereinander ausgeführt werden. Um sie zu trennen, verwenden Sie einen regulären Ausdruck in Ihrer $GIT_DIR/config- oder $HOME/.gitconfig-Datei wie folgt:

Für alle im vorherigen Abschnitt aufgeführten Sprachen ist ein integriertes Muster vorhanden.

Manchmal ist es wünschenswert, die Unterschiede einer textkonvertierten Version von Binärdateien anzuzeigen. Zum Beispiel kann ein Textverarbeitungsdokument in eine ASCII-Textdarstellung konvertiert und der Diff des Textes angezeigt werden. Obwohl diese Konvertierung einige Informationen verliert, ist der resultierende Diff für die menschliche Betrachtung nützlich (kann aber nicht direkt angewendet werden).

Die Konfigurationsoption textconv wird verwendet, um ein Programm für die Durchführung einer solchen Konvertierung zu definieren. Das Programm sollte ein einzelnes Argument entgegennehmen, den Namen einer zu konvertierenden Datei, und den resultierenden Text auf stdout ausgeben.

Um beispielsweise die Diff-Informationen der EXIF-Daten einer Datei anstelle der Binärinformationen anzuzeigen (vorausgesetzt, Sie haben das Exif-Tool installiert), fügen Sie Ihrer $GIT_DIR/config- oder $HOME/.gitconfig-Datei einen Abschnitt wie folgt hinzu:

Da die Textkonvertierung langsam sein kann, insbesondere bei einer großen Anzahl von Konvertierungen mit git log -p, bietet Git einen Mechanismus zum Zwischenspeichern der Ausgabe und zur Verwendung in zukünftigen Diffs. Um das Caching zu aktivieren, setzen Sie die Variable "cachetextconv" in der Konfiguration Ihres Diff-Treibers. Zum Beispiel:

Dies speichert das Ergebnis der Ausführung von "exif" auf jedem Blob unbefristet im Cache. Wenn Sie die textconv-Konfigurationsvariable für einen Diff-Treiber ändern, wird Git den Cache automatisch ungültig machen und den textconv-Filter erneut ausführen. Wenn Sie den Cache manuell ungültig machen möchten (z. B. weil Ihre Version von "exif" aktualisiert wurde und jetzt bessere Ausgaben liefert), können Sie den Cache manuell mit git update-ref -d refs/notes/textconv/jpg entfernen (wobei "jpg" der Name des Diff-Treibers ist, wie im obigen Beispiel).

Wenn Sie Unterschiede zwischen binären oder speziell formatierten Blobs in Ihrem Repository anzeigen möchten, können Sie entweder einen externen Diff-Befehl verwenden oder textconv verwenden, um sie in ein diff-fähiges Textformat zu konvertieren. Welche Methode Sie wählen, hängt von Ihrer genauen Situation ab.

Der Vorteil der Verwendung eines externen Diff-Befehls liegt in der Flexibilität. Sie sind nicht an zeilenorientierte Änderungen gebunden, und die Ausgabe muss auch nicht wie ein einheitlicher Diff aussehen. Sie können Änderungen auf die für Ihr Datenformat am besten geeignete Weise lokalisieren und melden.

Ein textconv ist im Vergleich dazu viel einschränkender. Sie stellen eine Transformation der Daten in ein zeilenorientiertes Textformat bereit, und Git verwendet seine regulären Diff-Tools, um die Ausgabe zu generieren. Es gibt mehrere Vorteile, diese Methode zu wählen:

Git errät normalerweise korrekt, ob ein Blob Text- oder Binärdaten enthält, indem es den Anfang des Inhalts untersucht. Manchmal möchten Sie seine Entscheidung jedoch überschreiben, entweder weil ein Blob später in der Datei Binärdaten enthält oder weil der Inhalt, obwohl technisch aus Textzeichen bestehend, für einen menschlichen Leser undurchsichtig ist. Beispielsweise enthalten viele Postscript-Dateien nur ASCII-Zeichen, erzeugen aber verrauschte und bedeutungslose Diffs.

Der einfachste Weg, eine Datei als binär zu kennzeichnen, ist das Aufheben des Diff-Attributs in der Datei .gitattributes

Dies veranlasst Git, Binary files differ (oder einen Binärpatch, wenn Binärpatches aktiviert sind) anstelle eines regulären Diffs zu generieren.

Manchmal möchte man jedoch auch andere Diff-Treiberattribute angeben. Man möchte zum Beispiel vielleicht textconv verwenden, um Postscript-Dateien in eine ASCII-Darstellung zur menschlichen Betrachtung zu konvertieren, sie aber ansonsten als Binärdateien zu behandeln. Sie können nicht gleichzeitig die Attribute -diff und diff=ps angeben. Die Lösung ist die Verwendung der Konfigurationsoption diff.*.binary

Das Attribut merge beeinflusst, wie drei Versionen einer Datei zusammengeführt werden, wenn während git merge und anderen Befehlen wie git revert und git cherry-pick ein Dateiebenen-Merge erforderlich ist.

Es gibt einige eingebaute Low-Level-Merge-Treiber, die über das Attribut merge angefordert werden können.

Die Definition eines Merge-Treibers erfolgt in der Datei .git/config, nicht in der Datei gitattributes. Streng genommen ist diese Manpage also der falsche Ort, um darüber zu sprechen. Aber trotzdem...

Um einen benutzerdefinierten Merge-Treiber filfre zu definieren, fügen Sie Ihrer $GIT_DIR/config- oder $HOME/.gitconfig-Datei einen Abschnitt wie diesen hinzu:

Die Variable merge.*.name gibt dem Treiber einen lesbaren Namen.

Der Wert der Variable merge.*.driver wird verwendet, um einen Befehl zu erstellen, der mit der Version des gemeinsamen Vorfahren (%O), der aktuellen Version (%A) und der Version des anderen Branches (%B) ausgeführt wird. Diese drei Platzhalter werden durch die Namen temporärer Dateien ersetzt, die die Inhalte dieser Versionen enthalten, wenn die Befehlszeile erstellt wird. Zusätzlich wird %L durch die Größe der Konfliktmarker (siehe unten) ersetzt.

Es wird erwartet, dass der Merge-Treiber das Ergebnis des Merges in der mit %A benannten Datei hinterlässt, indem er sie überschreibt, und mit Null-Status beendet wird, wenn er sie sauber zusammenführen konnte, oder mit einem Nicht-Null-Status, wenn es Konflikte gab. Wenn der Treiber abstürzt (z. B. durch SEGV beendet wird), wird erwartet, dass er mit einem Nicht-Null-Status größer als 128 beendet wird, und in diesem Fall führt der Merge zu einem Fehler (was sich von der Erzeugung eines Konflikts unterscheidet).

Die Variable merge.*.recursive gibt an, welcher andere Merge-Treiber verwendet werden soll, wenn der Merge-Treiber für einen internen Merge zwischen gemeinsamen Vorfahren aufgerufen wird, wenn es mehr als einen gibt. Wenn sie nicht angegeben ist, wird der Treiber selbst sowohl für den internen Merge als auch für den endgültigen Merge verwendet.

Der Merge-Treiber kann den Pfadnamen, in dem das zusammengeführte Ergebnis gespeichert wird, über den Platzhalter %P erfahren. Die Konfliktbeschriftungen für den gemeinsamen Vorfahren, den lokalen Head und den anderen Head können über %S, %X und %Y übergeben werden.

Dieses Attribut steuert die Länge der Konfliktmarker, die in der Arbeitsbaumdatei während eines konfliktreichen Merges hinterlassen werden. Nur eine positive Ganzzahl hat eine sinnvolle Auswirkung.

Zum Beispiel kann diese Zeile in .gitattributes verwendet werden, um der Merge-Mechanik mitzuteilen, viel längere (anstelle der üblichen 7-Zeichen-langen) Konfliktmarker zu hinterlassen, wenn das Zusammenführen der Datei Documentation/git-merge.adoc zu einem Konflikt führt.

Die Konfigurationsvariable core.whitespace ermöglicht es Ihnen, zu definieren, was diff und apply für alle Pfade im Projekt als Whitespace-Fehler betrachten sollen (siehe git-config[1]). Dieses Attribut gibt Ihnen eine feinere Kontrolle pro Pfad.

Dateien und Verzeichnisse mit dem Attribut export-ignore werden nicht zu Archivdateien hinzugefügt.

Wenn das Attribut export-subst für eine Datei gesetzt ist, erweitert Git beim Hinzufügen dieser Datei zu einem Archiv mehrere Platzhalter. Die Ersetzung hängt von der Verfügbarkeit einer Commit-ID ab, d. h., wenn git-archive[1] anstelle eines Commits oder Tags einen Baum erhalten hat, erfolgt keine Ersetzung. Die Platzhalter sind dieselben wie für die Option --pretty=format: von git-log[1], außer dass sie wie folgt eingekapselt werden müssen: $Format:PLACEHOLDERS$ in der Datei. Z. B. wird der String $Format:%H$ durch den Commit-Hash ersetzt. Es wird jedoch nur ein %(describe)-Platzhalter pro Archiv erweitert, um Denial-of-Service-Angriffe zu vermeiden.

Die Delta-Kompression wird für Blobs unter Pfaden, bei denen das Attribut delta auf false gesetzt ist, nicht versucht.

Der Wert dieses Attributs gibt die Zeichenkodierung an, die von GUI-Tools (z. B. gitk[1] und git-gui[1]) zur Anzeige des Inhalts der betreffenden Datei verwendet werden soll. Beachten Sie, dass gitk[1] aus Leistungsgründen dieses Attribut nicht verwendet, es sei denn, Sie aktivieren manuell Dateikodierungen in seinen Optionen.

Wenn dieses Attribut nicht gesetzt ist oder einen ungültigen Wert hat, wird stattdessen der Wert der Konfigurationsvariable gui.encoding verwendet (siehe git-config[1]).