English ▾ Themen ▾ Neueste Version ▾ git-format-patch zuletzt aktualisiert in 2.52.0

NAME

git-format-patch - Patches für E-Mail-Einreichung vorbereiten

SYNOPSIS

git format-patch [-k] [(-o|--output-directory) <dir> | --stdout]
		   [--no-thread | --thread[=<style>]]
		   [(--attach|--inline)[=<boundary>] | --no-attach]
		   [-s | --signoff]
		   [--signature=<signature> | --no-signature]
		   [--signature-file=<file>]
		   [-n | --numbered | -N | --no-numbered]
		   [--start-number <n>] [--numbered-files]
		   [--in-reply-to=<message-id>] [--suffix=.<sfx>]
		   [--ignore-if-in-upstream] [--always]
		   [--cover-from-description=<mode>]
		   [--rfc[=<rfc>]] [--subject-prefix=<subject-prefix>]
		   [(--reroll-count|-v) <n>]
		   [--to=<email>] [--cc=<email>]
		   [--[no-]cover-letter] [--quiet]
		   [--[no-]encode-email-headers]
		   [--no-notes | --notes[=<ref>]]
		   [--interdiff=<previous>]
		   [--range-diff=<previous> [--creation-factor=<percent>]]
		   [--filename-max-length=<n>]
		   [--progress]
		   [<common-diff-options>]
		   [ <since> | <revision-range> ]

BESCHREIBUNG

Bereitet jeden Nicht-Merge-Commit mit seinem "Patch" in einer "Nachricht" pro Commit vor, formatiert, um einer UNIX-Mailbox zu ähneln. Die Ausgabe dieses Befehls ist praktisch für die E-Mail-Einreichung oder für die Verwendung mit git am.

Eine von diesem Befehl generierte "Nachricht" besteht aus drei Teilen:

  • Ein kurzer Metadaten-Header, der mit From <commit> beginnt, mit einem festen Mon Sep 17 00:00:00 2001 Zeitstempel, um Programmen wie "file(1)" zu helfen zu erkennen, dass die Datei eine Ausgabe dieses Befehls ist, Felder, die die Autor-Identität, das Autor-Datum und den Titel der Änderung (entnommen aus dem ersten Absatz der Commit-Log-Nachricht) aufzeichnen.

  • Der zweite und nachfolgende Absätze der Commit-Log-Nachricht.

  • Der "Patch", der die Ausgabe von "diff -p --stat" ist (siehe git-diff[1]) zwischen dem Commit und seinem Elternteil.

Die Log-Nachricht und der Patch werden durch eine Zeile mit drei Bindestrichen getrennt.

Es gibt zwei Möglichkeiten, die zu bearbeitenden Commits anzugeben.

  1. Ein einzelner Commit, <seit>, gibt an, dass die Commits, die zur Spitze des aktuellen Branches führen und die nicht in der Historie sind, die zu <seit> führt, ausgegeben werden sollen.

  2. Ein generischer <Revisionsbereich>-Ausdruck (siehe Abschnitt "SPEZIFIZIERUNG VON REVISIONEN" in gitrevisions[7]) bedeutet die Commits im angegebenen Bereich.

Die erste Regel hat Vorrang im Falle eines einzelnen <commit>. Um die zweite Regel anzuwenden, d.h. alles seit Beginn der Historie bis zu <commit> zu formatieren, verwenden Sie die Option --root: git format-patch --root <commit>. Wenn Sie nur <commit> selbst formatieren möchten, können Sie dies mit git format-patch -1 <commit> tun.

Standardmäßig wird jede Ausgabedatei sequenziell von 1 nummeriert und die erste Zeile der Commit-Nachricht (bereinigt für Pfadsicherheit) als Dateiname verwendet. Mit der Option --numbered-files sind die Ausgabedateinamen nur Nummern, ohne die erste Zeile des Commits angehängt. Die Namen der Ausgabedateien werden auf die Standardausgabe gedruckt, es sei denn, die Option --stdout ist angegeben.

Wenn -o angegeben ist, werden Ausgabedateien in <dir> erstellt. Andernfalls werden sie im aktuellen Arbeitsverzeichnis erstellt. Der Standardpfad kann mit der Konfigurationsoption format.outputDirectory gesetzt werden. Die Option -o hat Vorrang vor format.outputDirectory. Um Patches im aktuellen Arbeitsverzeichnis zu speichern, auch wenn format.outputDirectory woanders hinzeigt, verwenden Sie -o .. Alle Verzeichnis-Komponenten werden erstellt.

Standardmäßig lautet der Betreff eines einzelnen Patches "[PATCH] ", gefolgt von der Aneinanderreihung von Zeilen aus der Commit-Nachricht bis zur ersten Leerzeile (siehe Abschnitt "DISKUSSION" in git-commit[1]).

Wenn mehrere Patches ausgegeben werden, ist das Betreff-Präfix stattdessen "[PATCH n/m] ". Um 1/1 für einen einzelnen Patch zu erzwingen, verwenden Sie -n. Um Patch-Nummern aus dem Betreff zu entfernen, verwenden Sie -N.

Wenn --thread angegeben ist, generiert git-format-patch In-Reply-To und References Header, damit die zweiten und nachfolgenden Patch-Mails als Antworten auf die erste Mail erscheinen; dies generiert auch einen Message-ID Header, auf den verwiesen wird.

OPTIONEN

-p
--no-stat

Erzeugt einfache Patches ohne Diff-Statistiken.

-U<n>
--unified=<n>

Erzeugt Diffs mit <n> Kontextzeilen anstelle der üblichen drei.

--output=<file>

Ausgabe in eine bestimmte Datei anstelle von stdout.

--output-indicator-new=<char>
--output-indicator-old=<char>
--output-indicator-context=<char>

Legt das Zeichen fest, das verwendet wird, um neue, alte oder Kontextzeilen im generierten Patch anzuzeigen. Normalerweise sind dies +, - und ' '.

--indent-heuristic

Aktiviert die Heuristik, die Diff-Hunk-Grenzen verschiebt, um Patches leichter lesbar zu machen. Dies ist der Standard.

--no-indent-heuristic

Deaktiviert die Einrückungsheuristik.

--minimal

Verwendet zusätzliche Zeit, um sicherzustellen, dass der kleinstmögliche Diff erzeugt wird.

--patience

Generiert einen Diff mit dem "Patience Diff"-Algorithmus.

--histogram

Generiert einen Diff mit dem "Histogramm Diff"-Algorithmus.

--anchored=<text>

Generiert einen Diff mit dem "Anchored Diff"-Algorithmus.

Diese Option kann mehrfach angegeben werden.

Wenn eine Zeile sowohl in der Quelle als auch im Ziel existiert, nur einmal vorkommt und mit <text> beginnt, versucht dieser Algorithmus zu verhindern, dass sie als Löschung oder Hinzufügung in der Ausgabe erscheint. Er verwendet intern den "Patience Diff"-Algorithmus.

--diff-algorithm=(patience|minimal|histogram|myers)

Wählt einen Diff-Algorithmus aus. Die Varianten sind wie folgt:

default
myers

Der grundlegende Greedy-Diff-Algorithmus. Derzeit ist dies der Standard.

minimal

Verwendet zusätzliche Zeit, um sicherzustellen, dass der kleinstmögliche Diff erzeugt wird.

patience

Verwendet den "Patience Diff"-Algorithmus bei der Generierung von Patches.

histogram

Dieser Algorithmus erweitert den Patience-Algorithmus, um "gemeinsame Elemente mit geringer Häufigkeit" zu unterstützen.

Wenn Sie beispielsweise die Variable diff.algorithm auf einen anderen Wert als den Standardwert konfiguriert haben und den Standardwert verwenden möchten, müssen Sie die Option --diff-algorithm=default verwenden.

--stat[=<width>[,<name-width>[,<count>]]]

Erzeugt eine Diff-Statistik. Standardmäßig wird für den Dateinamen-Teil so viel Platz wie nötig verwendet, und der Rest für den Graph-Teil. Die maximale Breite ist standardmäßig die Terminalbreite oder 80 Spalten, wenn nicht an ein Terminal angeschlossen, und kann durch <width> überschrieben werden. Die Breite des Dateinamen-Teils kann begrenzt werden, indem eine weitere Breite <name-width> nach einem Komma angegeben wird oder indem diff.statNameWidth=<name-width> gesetzt wird. Die Breite des Graph-Teils kann durch Verwendung von --stat-graph-width=<graph-width> oder durch Setzen von diff.statGraphWidth=<graph-width> begrenzt werden. Die Verwendung von --stat oder --stat-graph-width wirkt sich auf alle Befehle aus, die einen Statistik-Graphen erzeugen, während das Setzen von diff.statNameWidth oder diff.statGraphWidth git format-patch nicht beeinflusst. Durch Angabe eines dritten Parameters <count> können Sie die Ausgabe auf die ersten <count> Zeilen beschränken, gefolgt von ..., wenn mehr vorhanden sind.

Diese Parameter können auch einzeln mit --stat-width=<width>, --stat-name-width=<name-width> und --stat-count=<count> eingestellt werden.

--compact-summary

Gibt eine komprimierte Zusammenfassung von erweiterten Kopfzeileninformationen aus, wie z. B. Dateierstellungen oder -löschungen ("new" oder "gone", optional +l bei Symlinks) und Modusänderungen (+x oder -x zum Hinzufügen oder Entfernen des ausführbaren Bits) im Diffstat. Die Informationen werden zwischen dem Dateinamen-Teil und dem Grafik-Teil platziert. Beinhaltet --stat.

--numstat

Ähnlich wie --stat, zeigt aber die Anzahl der hinzugefügten und gelöschten Zeilen in Dezimaldarstellung und den Pfadnamen ohne Abkürzung an, um ihn maschinenfreundlicher zu machen. Für Binärdateien werden zwei - ausgegeben, anstatt 0 0 anzuzeigen.

--shortstat

Gibt nur die letzte Zeile des --stat Formats aus, die die Gesamtzahl der geänderten Dateien sowie die Anzahl der hinzugefügten und gelöschten Zeilen enthält.

-X [<param>,...]
--dirstat[=<param>,...]

Gibt die Verteilung des relativen Änderungsanteils für jedes Unterverzeichnis aus. Das Verhalten von --dirstat kann durch Übergabe einer kommagetrennten Liste von Parametern angepasst werden. Die Standardwerte werden durch die Konfigurationsvariable diff.dirstat gesteuert (siehe git-config[1]). Folgende Parameter sind verfügbar:

changes

Berechnet die Dirstat-Zahlen durch Zählen der aus der Quelle entfernten oder in das Ziel hinzugefügten Zeilen. Dies ignoriert den Umfang reiner Codebewegungen innerhalb einer Datei. Mit anderen Worten, das Neuordnen von Zeilen in einer Datei wird nicht so stark gezählt wie andere Änderungen. Dies ist das Standardverhalten, wenn kein Parameter angegeben wird.

lines

Berechnet die Dirstat-Zahlen, indem die reguläre zeilenbasierte Diff-Analyse durchgeführt und die Anzahl der entfernten/hinzugefügten Zeilen summiert wird. (Für Binärdateien werden stattdessen 64-Byte-Chunks gezählt, da Binärdateien kein natürliches Konzept von Zeilen haben.) Dies ist ein teureres --dirstat-Verhalten als das changes-Verhalten, zählt aber auch neu angeordnete Zeilen innerhalb einer Datei ebenso wie andere Änderungen. Die resultierende Ausgabe stimmt mit dem überein, was Sie von den anderen --*stat-Optionen erhalten.

files

Berechnet die Dirstat-Zahlen durch Zählen der Anzahl der geänderten Dateien. Jede geänderte Datei zählt gleichmäßig in der Dirstat-Analyse. Dies ist das rechnerisch günstigste --dirstat-Verhalten, da es den Dateiinhalt überhaupt nicht berücksichtigen muss.

cumulative

Zählt die Änderungen in einem Unterverzeichnis auch für das übergeordnete Verzeichnis. Beachten Sie, dass bei Verwendung von cumulative die Summe der angezeigten Prozentsätze 100 % überschreiten kann. Das Standardverhalten (nicht kumulativ) kann mit dem Parameter noncumulative angegeben werden.

<limit>

Ein Integer-Parameter gibt einen Schwellenwertprozentsatz an (standardmäßig 3 %). Verzeichnisse, die weniger als dieser Prozentsatz der Änderungen beitragen, werden nicht in der Ausgabe angezeigt.

Beispiel: Folgendes zählt geänderte Dateien, ignoriert aber Verzeichnisse mit weniger als 10 % des gesamten Anteils an geänderten Dateien und akkumuliert die Zählungen von Unterverzeichnissen in den übergeordneten Verzeichnissen: --dirstat=files,10,cumulative.

--cumulative

Synonym für --dirstat=cumulative.

--dirstat-by-file[=<param>,...]

Synonym für --dirstat=files,<param>,....

--summary

Gibt eine komprimierte Zusammenfassung von erweiterten Kopfzeileninformationen aus, wie z. B. Erstellungen, Umbenennungen und Modusänderungen.

--no-renames

Umbenennungserkennung deaktivieren, auch wenn die Konfigurationsdatei dies standardmäßig vorgibt.

--rename-empty
--no-rename-empty

Ob leere Blobs als Umbenennungsquelle verwendet werden sollen.

--full-index

Zeigt anstelle der ersten paar Zeichen die vollständigen Blob-Objekt-Namen vor und nach der Änderung in der "index"-Zeile an, wenn die Patch-Format-Ausgabe generiert wird.

--binary

Zusätzlich zu --full-index wird ein binärer Diff ausgegeben, der mit git-apply angewendet werden kann.

--abbrev[=<n>]

Anstatt den vollständigen 40-Byte-Hexadezimalnamen eines Objekts im diff-raw-Format und in den Kopfzeilen des diff-tree-Formats anzuzeigen, wird der kürzeste Präfix angezeigt, der mindestens <n> Hexadezimalziffern lang ist und das Objekt eindeutig identifiziert. Im diff-patch-Ausgabeformat hat --full-index höhere Priorität, d.h. wenn --full-index angegeben ist, werden vollständige Blob-Namen unabhängig von --abbrev angezeigt. Eine nicht standardmäßige Anzahl von Ziffern kann mit --abbrev=<n> angegeben werden.

-B[<n>][/<m>]
--break-rewrites[=[<n>][/<m>]]

Zerlegen Sie vollständige Umschreibungsänderungen in Paare aus Löschung und Erstellung. Dies dient zwei Zwecken

Es beeinflusst die Art und Weise, wie eine Änderung, die einer vollständigen Umschreibung einer Datei entspricht, nicht als eine Reihe von Löschungen und Einfügungen, die mit sehr wenigen passenden Textzeilen als Kontext vermischt sind, sondern als eine einzelne Löschung des alten und eine einzelne Einfügung des neuen dargestellt wird. Die Zahl <m> steuert diesen Aspekt der Option -B (standardmäßig 60%). -B/70% gibt an, dass weniger als 30% des Originals im Ergebnis verbleiben müssen, damit Git dies als vollständige Umschreibung betrachtet (andernfalls wird der resultierende Patch eine Reihe von Löschungen und Einfügungen mit Kontextzeilen sein).

Wenn mit -M verwendet, wird eine vollständig umgeschriebene Datei auch als Quelle einer Umbenennung betrachtet (normalerweise betrachtet -M nur eine verschwundene Datei als Quelle einer Umbenennung). Die Zahl <n> steuert diesen Aspekt der Option -B (standardmäßig 50%). -B20% gibt an, dass eine Änderung mit Hinzufügungen und Löschungen im Verhältnis zu 20% oder mehr der Dateigröße als mögliche Quelle für eine Umbenennung in eine andere Datei in Betracht gezogen werden kann.

-M[<n>]
--find-renames[=<n>]

Erkennt Umbenennungen. Wenn <n> angegeben ist, ist es ein Schwellenwert für den Ähnlichkeitsindex (d.h. die Menge an Hinzufügungen/Löschungen im Verhältnis zur Dateigröße). Zum Beispiel bedeutet -M90%, dass Git ein Lösch-/Hinzufügepaar als Umbenennung betrachten sollte, wenn mehr als 90 % der Datei unverändert geblieben sind. Ohne ein %-Zeichen wird die Zahl als Bruch mit einem Dezimalpunkt davor gelesen. D.h., -M5 wird zu 0,5 und ist somit dasselbe wie -M50%. Ebenso ist -M05 dasselbe wie -M5%. Um die Erkennung auf exakte Umbenennungen zu beschränken, verwenden Sie -M100%. Der Standard-Ähnlichkeitsindex ist 50 %.

-C[<n>]
--find-copies[=<n>]

Erkennt auch Kopien sowie Umbenennungen. Siehe auch --find-copies-harder. Wenn <n> angegeben ist, hat es die gleiche Bedeutung wie bei -M<n>.

--find-copies-harder

Aus Leistungsgründen erkennt die Option -C standardmäßig Kopien nur dann, wenn die Originaldatei der Kopie im selben Änderungssatz geändert wurde. Dieses Flag bewirkt, dass der Befehl auch unveränderte Dateien als Kandidaten für die Quelle einer Kopie untersucht. Dies ist eine sehr aufwendige Operation für große Projekte, daher sollte sie mit Vorsicht verwendet werden. Die Angabe von mehr als einer -C Option hat die gleiche Wirkung.

-D
--irreversible-delete

Unterdrückt die Vorabinformationen für Löschungen, d.h. gibt nur den Header aus, aber nicht den Unterschied zwischen der Vorabinformation und /dev/null. Der resultierende Patch ist nicht dafür bestimmt, mit patch oder git apply angewendet zu werden; dies ist ausschließlich für Personen gedacht, die sich nur auf die Überprüfung des Textes nach der Änderung konzentrieren möchten. Darüber hinaus fehlen offensichtlich genügend Informationen, um einen solchen Patch umgekehrt anzuwenden, selbst manuell, daher der Name der Option.

Wenn zusammen mit -B verwendet, werden auch die Vorabinformationen im Löschteil eines Lösch-/Erstellungspaares unterdrückt.

-l<num>

Die Optionen -M und -C beinhalten einige vorbereitende Schritte, die Teilmengen von Umbenennungen/Kopien kostengünstig erkennen können, gefolgt von einem vollständigen Fallback-Teil, der alle verbleibenden ungepaarten Ziele mit allen relevanten Quellen vergleicht. (Für Umbenennungen sind nur verbleibende ungepaarte Quellen relevant; für Kopien sind alle ursprünglichen Quellen relevant.) Für N Quellen und Ziele ist dieser vollständige Vergleich O(N^2). Diese Option verhindert, dass der vollständige Teil der Umbenennungs-/Kopiererkennung ausgeführt wird, wenn die Anzahl der beteiligten Quell-/Ziel-Dateien die angegebene Zahl überschreitet. Standardmäßig wird diff.renameLimit verwendet. Beachten Sie, dass ein Wert von 0 als unbegrenzt behandelt wird.

-O<orderfile>

Steuert die Reihenfolge, in der Dateien in der Ausgabe erscheinen. Dies überschreibt die Konfigurationsvariable diff.orderFile (siehe git-config[1]). Um diff.orderFile abzubrechen, verwenden Sie -O/dev/null.

Die Ausgabereihenfolge wird durch die Reihenfolge der Glob-Muster in <orderfile> bestimmt. Alle Dateien mit Pfadnamen, die mit dem ersten Muster übereinstimmen, werden zuerst ausgegeben, alle Dateien mit Pfadnamen, die mit dem zweiten Muster (aber nicht mit dem ersten) übereinstimmen, werden als nächstes ausgegeben, und so weiter. Alle Dateien mit Pfadnamen, die keinem Muster entsprechen, werden zuletzt ausgegeben, als ob ein implizites Muster für alles am Ende der Datei stünde. Wenn mehrere Pfadnamen den gleichen Rang haben (sie stimmen mit demselben Muster, aber keinen früheren Mustern überein), ist ihre relative Ausgabereihenfolge die normale.

<orderfile> wird wie folgt analysiert

  • Leere Zeilen werden ignoriert und können als Trennzeichen zur besseren Lesbarkeit verwendet werden.

  • Zeilen, die mit einem Hash ("#") beginnen, werden ignoriert, sodass sie für Kommentare verwendet werden können. Fügen Sie einen Backslash ("\") am Anfang des Musters hinzu, wenn es mit einem Hash beginnt.

  • Jede andere Zeile enthält ein einzelnes Muster.

Muster haben die gleiche Syntax und Semantik wie Muster, die für fnmatch(3) ohne das Flag FNM_PATHNAME verwendet werden, mit der Ausnahme, dass ein Pfadname auch dann mit einem Muster übereinstimmt, wenn das Entfernen einer beliebigen Anzahl der letzten Pfadkomponenten mit dem Muster übereinstimmt. Zum Beispiel passt das Muster "foo*bar" auf "fooasdfbar" und "foo/bar/baz/asdf", aber nicht auf "foobarx".

--skip-to=<file>
--rotate-to=<file>

Verwerfen Sie die Dateien vor der benannten <file> aus der Ausgabe (d.h. skip to) oder verschieben Sie sie ans Ende der Ausgabe (d.h. rotate to). Diese Optionen wurden hauptsächlich für die Verwendung des Befehls git difftool entwickelt und sind möglicherweise sonst nicht sehr nützlich.

--relative[=<path>]
--no-relative

Wenn von einem Unterverzeichnis des Projekts aus ausgeführt, kann es angewiesen werden, Änderungen außerhalb des Verzeichnisses auszuschließen und Pfadnamen relativ dazu mit dieser Option anzuzeigen. Wenn Sie sich nicht in einem Unterverzeichnis befinden (z.B. in einem Bare-Repository), können Sie angeben, welches Unterverzeichnis die Ausgabe relativ dazu machen soll, indem Sie <path> als Argument angeben. --no-relative kann verwendet werden, um sowohl die Konfigurationsoption diff.relative als auch die vorherige Option --relative zu widerrufen.

-a
--text

Behandeln Sie alle Dateien als Text.

--ignore-cr-at-eol

Ignoriert Wagenrücklauf am Zeilenende beim Vergleichen.

--ignore-space-at-eol

Ignoriert Änderungen an Leerzeichen am Zeilenende.

-b
--ignore-space-change

Ignoriert Änderungen an der Leerzeichenmenge. Dies ignoriert Leerzeichen am Zeilenende und betrachtet alle anderen Sequenzen von einem oder mehreren Leerzeichen als äquivalent.

-w
--ignore-all-space

Ignoriert Leerzeichen beim Vergleich von Zeilen. Dies ignoriert Unterschiede, auch wenn eine Zeile Leerzeichen enthält, während die andere Zeile keine hat.

--ignore-blank-lines

Ignoriert Änderungen, deren Zeilen alle leer sind.

-I<regex>
--ignore-matching-lines=<regex>

Ignoriert Änderungen, deren alle Zeilen mit <regex> übereinstimmen. Diese Option kann mehr als einmal angegeben werden.

--inter-hunk-context=<number>

Zeigt den Kontext zwischen Diff-Hunks bis zur angegebenen Anzahl von <n> Zeilen an und fasst so nahe beieinander liegende Hunks zusammen. Standard ist diff.interHunkContext oder 0, wenn die Konfigurationsoption nicht gesetzt ist.

-W
--function-context

Zeigt die gesamte Funktion als Kontextzeilen für jede Änderung an. Die Funktionsnamen werden auf die gleiche Weise bestimmt, wie git diff Patch-Hunk-Header erstellt (siehe "Defining a custom hunk-header" in gitattributes[5]).

--ext-diff

Ermöglicht die Ausführung eines externen Diff-Helferprogramms. Wenn Sie einen externen Diff-Treiber mit gitattributes[5] einrichten, müssen Sie diese Option mit git-log[1] und ähnlichen Befehlen verwenden.

--no-ext-diff

Deaktiviert externe Diff-Treiber.

--textconv
--no-textconv

Erlaubt (oder verbietet) die Ausführung externer Textkonvertierungsfilter beim Vergleichen von Binärdateien. Siehe gitattributes[5] für Details. Da Textkonvertierungsfilter typischerweise eine unidirektionale Konvertierung sind, ist der resultierende Diff für den menschlichen Gebrauch geeignet, kann aber nicht angewendet werden. Aus diesem Grund sind Textkonvertierungsfilter standardmäßig nur für git-diff[1] und git-log[1] aktiviert, aber nicht für git-format-patch[1] oder Diff-Plumbing-Befehle.

--ignore-submodules[=(none|untracked|dirty|all)]

Ignoriert Änderungen an Submodulen bei der Diff-Erstellung. all ist der Standard. Die Verwendung von none betrachtet das Submodul als geändert, wenn es entweder ungetrackte oder geänderte Dateien enthält oder sein HEAD vom im Superprojekt aufgezeichneten Commit abweicht, und kann verwendet werden, um beliebige Einstellungen der ignore-Option in git-config[1] oder gitmodules[5] zu überschreiben. Wenn untracked verwendet wird, werden Submodule nicht als schmutzig betrachtet, wenn sie nur ungetrackten Inhalt enthalten (sie werden aber immer noch auf geänderte Inhalte geprüft). Die Verwendung von dirty ignoriert alle Änderungen am Arbeitsbaum von Submodulen, nur Änderungen an den im Superprojekt gespeicherten Commits werden angezeigt (dies war das Verhalten bis 1.7.0). Die Verwendung von all blendet alle Änderungen an Submodulen aus.

--src-prefix=<prefix>

Zeigt den angegebenen Quell-<prefix> anstelle von "a/" an.

--dst-prefix=<prefix>

Zeigt den angegebenen Ziel-<prefix> anstelle von "b/" an.

--no-prefix

Zeigt keine Quell- oder Zielpräfixe an.

--default-prefix

Verwendet die Standard-Quell- und Zielpräfixe ("a/" und "b/"). Dies überschreibt Konfigurationsvariablen wie diff.noprefix, diff.srcPrefix, diff.dstPrefix und diff.mnemonicPrefix (siehe git-config[1]).

--line-prefix=<prefix>

Fügt jeder Zeile der Ausgabe einen zusätzlichen <prefix> voran.

--ita-invisible-in-index

Standardmäßig erscheinen Einträge, die mit git add -N hinzugefügt wurden, als existierende leere Datei in git diff und als neue Datei in git diff --cached. Diese Option bewirkt, dass der Eintrag als neue Datei in git diff und als nicht vorhanden in git diff --cached erscheint. Diese Option kann mit --ita-visible-in-index rückgängig gemacht werden. Beide Optionen sind experimentell und können in zukünftigen Versionen entfernt werden.

--max-depth=<depth>

Für jeden auf der Kommandozeile angegebenen Pfadspec wird maximal bis zur Tiefe von <depth> Ebenen von Verzeichnissen abgestiegen. Ein Wert von -1 bedeutet keine Begrenzung. Kann nicht mit Wildcards im Pfadspec kombiniert werden. Bei einem Baum, der foo/bar/baz enthält, zeigt die folgende Liste die Übereinstimmungen, die von jeder Optionsmenge generiert werden

  • --max-depth=0 -- foo: foo

  • --max-depth=1 -- foo: foo/bar

  • --max-depth=1 -- foo/bar: foo/bar/baz

  • --max-depth=1 -- foo foo/bar: foo/bar/baz

  • --max-depth=2 -- foo: foo/bar/baz

Wenn kein Pfadspec angegeben ist, wird die Tiefe gemessen, als ob alle Top-Level-Einträge angegeben wären. Beachten Sie, dass dies anders ist, als von der Wurzel aus zu messen, da --max-depth=0 immer noch foo zurückgeben würde. Dies ermöglicht es Ihnen, die Tiefe weiterhin zu begrenzen, während Sie eine Teilmenge der Top-Level-Einträge anfordern.

Beachten Sie, dass diese Option nur für Diffs zwischen Baum-Objekten unterstützt wird, nicht gegen den Index oder den Arbeitsbaum.

Für eine detailliertere Erklärung dieser gängigen Optionen siehe auch gitdiffcore[7].

-<n>

Bereitet Patches aus den obersten <n> Commits vor.

-o <dir>
--output-directory <dir>

Verwendet <dir>, um die resultierenden Dateien zu speichern, anstelle des aktuellen Arbeitsverzeichnisses.

-n
--numbered

Benennt die Ausgabe im Format [PATCH n/m], auch bei einem einzelnen Patch.

-N
--no-numbered

Benennt die Ausgabe im Format [PATCH].

--start-number <n>

Beginnt mit der Nummerierung der Patches bei <n> anstelle von 1.

--numbered-files

Die Ausgabedateinamen sind eine einfache Zahlenfolge ohne die standardmäßige erste Zeile des Commits, die angehängt wird.

-k
--keep-subject

Entfernt/fügt [PATCH] nicht aus der ersten Zeile der Commit-Log-Nachricht.

-s
--signoff

Fügt einen Signed-off-by Trailer zur Commit-Nachricht hinzu, unter Verwendung der Committer-Identität von Ihnen selbst. Weitere Informationen finden Sie in der Option "signoff" in git-commit[1].

--stdout

Gibt alle Commits im mbox-Format auf die Standardausgabe aus, anstatt für jeden eine Datei zu erstellen.

--attach[=<boundary>]

Erstellt eine multipart/mixed-Anlage, deren erster Teil die Commit-Nachricht und der Patch selbst im zweiten Teil ist, mit Content-Disposition: attachment.

--no-attach

Deaktiviert die Erstellung einer Anlage und überschreibt die Konfigurationseinstellung.

--inline[=<boundary>]

Erstellt eine multipart/mixed-Anlage, deren erster Teil die Commit-Nachricht und der Patch selbst im zweiten Teil ist, mit Content-Disposition: inline.

--thread[=<style>]
--no-thread

Steuert die Hinzufügung von In-Reply-To und References Headern, damit die zweiten und nachfolgenden E-Mails als Antworten auf die erste erscheinen. Steuert auch die Generierung des Message-ID Headers, auf den verwiesen wird.

Das optionale Argument <style> kann entweder shallow oder deep sein. shallow Threading macht jede E-Mail zu einer Antwort auf den Kopf der Serie, wobei der Kopf aus dem Anschreiben, dem --in-reply-to und der ersten Patch-Mail ausgewählt wird, in dieser Reihenfolge. deep Threading macht jede E-Mail zu einer Antwort auf die vorherige.

Der Standard ist --no-thread, es sei denn, die Konfiguration format.thread ist gesetzt. --thread ohne Argument ist äquivalent zu --thread=shallow.

Beachten Sie, dass der Standard für git send-email darin besteht, E-Mails selbst zu verketten. Wenn Sie möchten, dass git format-patch das Verketten übernimmt, sollten Sie sicherstellen, dass das Verketten für git send-email deaktiviert ist.

--in-reply-to=<message-id>

Lässt die erste E-Mail (oder alle E-Mails mit --no-thread) als Antwort auf die angegebene <message-id> erscheinen, was das Aufbrechen von Threads zur Bereitstellung einer neuen Patch-Serie vermeidet.

--ignore-if-in-upstream

Schließt keinen Patch ein, der einem Commit in <until>..<seit> entspricht. Dies untersucht alle Patches, die von <seit> erreichbar sind, aber nicht von <until>, und vergleicht sie mit den zu generierenden Patches. Jeder übereinstimmende Patch wird ignoriert.

--always

Schließt Patches für Commits ein, die keine Änderungen einführen und standardmäßig weggelassen werden.

--cover-from-description=<mode>

Steuert, welche Teile des Anschreibens automatisch mit der Beschreibung des Branches gefüllt werden.

Wenn <mode> message oder default ist, wird der Betreff des Anschreibens mit Platzhaltertext gefüllt. Der Körper des Anschreibens wird mit der Beschreibung des Branches gefüllt. Dies ist der Standardmodus, wenn keine Konfiguration oder Kommandozeilenoption angegeben ist.

Wenn <mode> subject ist, füllt der erste Absatz der Branch-Beschreibung den Betreff des Anschreibens. Der Rest der Beschreibung füllt den Körper des Anschreibens.

Wenn <mode> auto ist und der erste Absatz der Branch-Beschreibung mehr als 100 Bytes lang ist, wird der Modus message verwendet, andernfalls wird subject verwendet.

Wenn <mode> none ist, werden sowohl der Betreff als auch der Körper des Anschreibens mit Platzhaltertext gefüllt.

--description-file=<file>

Verwendet den Inhalt von <file> anstelle der Beschreibung des Branches zur Generierung des Anschreibens.

--subject-prefix=<subject-prefix>

Anstelle des Standard-Präfixes [PATCH] in der Betreffzeile wird stattdessen [<subject-prefix>] verwendet. Dies kann verwendet werden, um eine Patch-Serie zu benennen, und kann mit der Option --numbered kombiniert werden.

Die Konfigurationsvariable format.subjectPrefix kann auch verwendet werden, um ein Betreff-Präfix für ein bestimmtes Repository für alle Patches zu konfigurieren. Dies ist oft nützlich für Mailinglisten, die Patches für mehrere Repositories erhalten und kann zur Unterscheidung der Patches verwendet werden (mit einem Wert von z.B. "PATCH my-project").

--filename-max-length=<n>

Anstelle der Standardlänge von 64 Bytes werden die generierten Ausgabedateinamen auf etwa <n> Bytes gekürzt (ein zu kurzer Wert wird stillschweigend auf eine vernünftige Länge erhöht). Standardmäßig wird der Wert der Konfigurationsvariable format.filenameMaxLength verwendet, oder 64, wenn nicht konfiguriert.

--rfc[=<rfc>]

Vor die Zeichenkette <rfc> (standardmäßig "RFC") wird eine Zeichenkette gestellt. Da das Betreff-Präfix standardmäßig "PATCH" ist, erhalten Sie standardmäßig "RFC PATCH".

RFC bedeutet "Request For Comments"; verwenden Sie dies, wenn Sie einen experimentellen Patch zur Diskussion und nicht zur Anwendung senden. "--rfc=WIP" kann auch eine nützliche Möglichkeit sein, anzuzeigen, dass ein Patch noch nicht fertig ist ("WIP" steht für "Work In Progress").

Wenn die Konvention der empfangenden Community für eine bestimmte zusätzliche Zeichenkette darin besteht, sie nach dem Betreff-Präfix zu haben, kann die Zeichenkette <rfc> mit einem Bindestrich ("-") vorangestellt werden, um anzuzeigen, dass der Rest der <rfc> Zeichenkette stattdessen an das Betreff-Präfix angehängt werden soll, z.B. --rfc='-(WIP) ergibt "PATCH (WIP)".

-v <n>
--reroll-count=<n>

Markiert die Serie als die <n>-te Iteration des Themas. Die Ausgabedateinamen erhalten v<n> vorangestellt und das Betreff-Präfix ("PATCH" standardmäßig, aber konfigurierbar über die Option --subject-prefix) erhält ` v<n>` angehängt. Z.B. kann --reroll-count=4 eine Datei v4-0001-add-makefile.patch erzeugen, die "Subject: [PATCH v4 1/20] Add makefile" enthält. <n> muss keine ganze Zahl sein (z.B. "--reroll-count=4.4" oder "--reroll-count=4rev2" sind zulässig), aber der Nachteil der Verwendung eines solchen Reroll-Counts ist, dass der Range-Diff/Interdiff mit der vorherigen Version nicht genau angibt, gegen welche Version die neue Iteration verglichen wird.

--to=<email>

Fügt einen To: Header zu den E-Mail-Headern hinzu. Dies geschieht zusätzlich zu allen konfigurierten Headern und kann mehrfach verwendet werden. Die negierte Form --no-to verwirft alle bisher hinzugefügten To: Header (aus Konfiguration oder Kommandozeile).

--cc=<email>

Fügt einen Cc: Header zu den E-Mail-Headern hinzu. Dies geschieht zusätzlich zu allen konfigurierten Headern und kann mehrfach verwendet werden. Die negierte Form --no-cc verwirft alle bisher hinzugefügten Cc: Header (aus Konfiguration oder Kommandozeile).

--from
--from=<ident>

Verwendet ident im From: Header jeder Commit-E-Mail. Wenn die Autor-Identität des Commits nicht textuell mit der angegebenen ident identisch ist, wird ein From: Header im Nachrichtentext mit dem ursprünglichen Autor platziert. Wenn keine ident angegeben ist, wird die Committer-Identität verwendet.

Beachten Sie, dass diese Option nur dann nützlich ist, wenn Sie tatsächlich E-Mails versenden und sich selbst als Absender identifizieren möchten, aber den ursprünglichen Autor beibehalten möchten (und git am korrekt die im Nachrichtentext enthaltenen Header erkennt). Beachten Sie auch, dass git send-email diese Transformation bereits für Sie durchführt, und diese Option nicht verwendet werden sollte, wenn Sie das Ergebnis an git send-email weiterleiten.

--force-in-body-from
--no-force-in-body-from

Mit dem über die Option --from angegebenen E-Mail-Absender wird standardmäßig ein "From:"-Header im Nachrichtentext am Anfang der Commit-Log-Nachricht hinzugefügt, um den tatsächlichen Autor des Commits zu identifizieren, falls der Absender vom Autor abweicht. Mit dieser Option wird der "From:"-Header im Nachrichtentext auch dann hinzugefügt, wenn Absender und Autor denselben Namen und dieselbe Adresse haben, was hilfreich sein kann, wenn die Mailinglisten-Software die Identität des Absenders verändert. Standardmäßig wird der Wert der Konfigurationsvariable format.forceInBodyFrom verwendet.

--add-header=<header>

Fügt einen beliebigen Header zu den E-Mail-Headern hinzu. Dies geschieht zusätzlich zu allen konfigurierten Headern und kann mehrmals verwendet werden. Zum Beispiel: --add-header="Organization: git-foo". Die negierte Form --no-add-header verwirft alle bisher hinzugefügten Header (aus Konfiguration oder Kommandozeile).

--cover-letter
--no-cover-letter

Zusätzlich zu den Patches wird eine Anschreiben-Datei generiert, die die Branch-Beschreibung, eine Kurzübersicht (shortlog) und die Gesamtdiffstat enthält. Sie können vor dem Versenden eine Beschreibung in diese Datei einfügen.

--encode-email-headers
--no-encode-email-headers

Kodiert E-Mail-Header mit Nicht-ASCII-Zeichen mit "Q-Encoding" (beschrieben in RFC 2047) anstatt die Header unverändert auszugeben. Standardmäßig wird der Wert der Konfigurationsvariable format.encodeEmailHeaders verwendet.

--interdiff=<previous>

Als Hilfsmittel für Gutachter wird ein Interdiff in das Anschreiben oder als Kommentar zum einzelnen Patch einer 1-Patch-Serie eingefügt, der die Unterschiede zwischen der vorherigen Version der Patch-Serie und der aktuell formatierten Serie zeigt. previous ist eine einzelne Revision, die die Spitze der vorherigen Serie benennt und eine gemeinsame Basis mit der zu formatierenden Serie hat (z. B. git format-patch --cover-letter --interdiff=feature/v1 -3 feature/v2).

--range-diff=<previous>

Als Hilfsmittel für Gutachter wird ein Range-Diff (siehe git-range-diff[1]) in das Anschreiben oder als Kommentar zum einzelnen Patch einer 1-Patch-Serie eingefügt, der die Unterschiede zwischen der vorherigen Version der Patch-Serie und der aktuell formatierten Serie zeigt. previous kann eine einzelne Revision sein, die die Spitze der vorherigen Serie benennt, wenn sie eine gemeinsame Basis mit der zu formatierenden Serie hat (z. B. git format-patch --cover-letter --range-diff=feature/v1 -3 feature/v2), oder ein Revisionsbereich, wenn die beiden Versionen der Serie disjoint sind (z. B. git format-patch --cover-letter --range-diff=feature/v1~3..feature/v1 -3 feature/v2).

Beachten Sie, dass Diff-Optionen, die an den Befehl übergeben werden, beeinflussen, wie das primäre Produkt von format-patch generiert wird, und dass sie nicht an die zugrunde liegende range-diff-Maschinerie weitergegeben werden, die zur Generierung des Anschreiben-Materials verwendet wird (dies kann sich in Zukunft ändern).

--creation-factor=<percent>

Wird mit --range-diff verwendet, um die Heuristik anzupassen, die Commits zwischen der vorherigen und der aktuellen Patch-Serie abgleicht, indem der Kostenfaktor für Erstellung/Löschung angepasst wird. Siehe git-range-diff[1] für Details.

Standardmäßig ist der Wert 999 (während git-range-diff[1] 60 verwendet), da der Anwendungsfall darin besteht, einen Vergleich mit einer älteren Iteration desselben Themas anzuzeigen und das Werkzeug mehr Übereinstimmungen zwischen den beiden Patch-Sätzen finden sollte.

--notes[=<ref>]
--no-notes

Fügt die Notizen (siehe git-notes[1]) für den Commit nach der Dreistrich-Linie an.

Der erwartete Anwendungsfall ist, erklärende Notizen zum Commit zu schreiben, die nicht Teil der eigentlichen Commit-Log-Nachricht sind, und sie mit der Patch-Einreichung zu versenden. Obwohl man diese Erklärungen einfach nach Ausführung von format-patch, aber vor dem Versenden, schreiben kann, ermöglicht die Speicherung als Git-Notizen die Wartung zwischen den Versionen der Patch-Serie (aber siehe die Diskussion der notes.rewrite-Konfigurationsoptionen in git-notes[1], um diesen Workflow zu nutzen).

Der Standardwert ist --no-notes, es sei denn, die Konfiguration format.notes ist gesetzt.

--signature=<signature>
--no-signature

Fügt jeder erzeugten Nachricht eine Signatur hinzu. Gemäß RFC 3676 wird die Signatur vom Hauptteil durch eine Zeile mit '-- ' getrennt. Wenn die Signaturoption weggelassen wird, ist die Signatur standardmäßig die Git-Versionsnummer.

--signature-file=<file>

Funktioniert genauso wie --signature, nur dass die Signatur aus einer Datei gelesen wird.

--suffix=.<sfx>

Anstatt .patch als Suffix für generierte Dateinamen zu verwenden, wird das angegebene Suffix verwendet. Eine gängige Alternative ist --suffix=.txt. Das Weglassen dieses Suffixes entfernt das .patch-Suffix.

Beachten Sie, dass das führende Zeichen kein Punkt sein muss; Sie können zum Beispiel --suffix=-patch verwenden, um 0001-description-of-my-change-patch zu erhalten.

-q
--quiet

Gibt die Namen der generierten Dateien nicht auf der Standardausgabe aus.

--no-binary

Gibt keine Inhalte von binären Dateien aus, sondern zeigt stattdessen eine Benachrichtigung an, dass diese Dateien geändert wurden. Mit dieser Option generierte Patches können nicht korrekt angewendet werden, sind aber immer noch für Code-Reviews nützlich.

--zero-commit

Gibt einen Hash aus lauter Nullen im From-Header jedes Patches aus, anstatt des Hashes des Commits.

--no-base
--base[=<commit>]

Speichert die Basis-Tree-Informationen, um den Zustand zu identifizieren, auf den die Patch-Serie angewendet wird. Siehe den Abschnitt BASE TREE INFORMATION unten für Details. Wenn <commit> "auto" ist, wird automatisch ein Basis-Commit ausgewählt. Die Option --no-base überschreibt die Konfiguration format.useAutoBase.

--root

Behandelt das Revisionsargument als <revisionsbereich>, auch wenn es nur ein einzelner Commit ist (der normalerweise als <seit> behandelt würde). Beachten Sie, dass Root-Commits, die im angegebenen Bereich enthalten sind, unabhängig von diesem Flag immer als Erstellungs-Patches formatiert werden.

--progress

Zeigt Fortschrittsberichte auf stderr an, während Patches generiert werden.

KONFIGURATION

Sie können zusätzliche E-Mail-Headerzeilen angeben, die zu jeder Nachricht hinzugefügt werden sollen, Standardwerte für Präfix und Dateisuffix festlegen, Patches nummerieren, wenn mehr als ein Patch ausgegeben wird, "To:"- oder "Cc:"-Header hinzufügen, Anhänge konfigurieren, das Patch-Ausgabeverzeichnis ändern und Patches mit Konfigurationsvariablen signieren.

[format]
	headers = "Organization: git-foo\n"
	subjectPrefix = CHANGE
	suffix = .txt
	numbered = auto
	to = <email>
	cc = <email>
	attach [ = mime-boundary-string ]
	signOff = true
	outputDirectory = <directory>
	coverLetter = auto
	coverFromDescription = auto

DISKUSSION

Der von git format-patch erzeugte Patch liegt im UNIX-Mailbox-Format vor, mit einem festen "magischen" Zeitstempel, der anzeigt, dass die Datei eine Ausgabe von format-patch und nicht eine echte Mailbox ist, wie folgt:

From 8f72bad1baf19a53459661343e21d6491c3908d3 Mon Sep 17 00:00:00 2001
From: Tony Luck <tony.luck@intel.com>
Date: Tue, 13 Jul 2010 11:42:54 -0700
Subject: [PATCH] =?UTF-8?q?[IA64]=20Put=20ia64=20config=20files=20on=20the=20?=
 =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20diet?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

arch/arm config files were slimmed down using a python script
(See commit c2330e286f68f1c408b4aa6515ba49d57f05beae comment)

Do the same for ia64 so we can have sleek & trim looking
...

Typischerweise wird er in den Entwurfsordner eines MUA gelegt, bearbeitet, um zeitnahe Kommentare hinzuzufügen, die nicht in den Changelog gehören, nach den drei Strichen, und dann als Nachricht gesendet, deren Hauptteil in unserem Beispiel mit "arch/arm config files were…" beginnt. Auf der Empfängerseite können Leser interessante Patches in einer UNIX-Mailbox speichern und sie mit git-am[1] anwenden.

Wenn ein Patch Teil einer laufenden Diskussion ist, kann der von git format-patch generierte Patch so angepasst werden, dass er die Funktion git am --scissors nutzt. Nach Ihrer Antwort auf die Diskussion folgt eine Zeile, die ausschließlich aus "-- >8 --" (Schere und Perforation) besteht, gefolgt von dem Patch mit entfernten unnötigen Headerfeldern.

...
> So we should do such-and-such.

Makes sense to me.  How about this patch?

-- >8 --
Subject: [IA64] Put ia64 config files on the Uwe Kleine-König diet

arch/arm config files were slimmed down using a python script
...

Wenn Sie einen Patch auf diese Weise versenden, versenden Sie höchstwahrscheinlich Ihren eigenen Patch. Daher sollten Sie zusätzlich zum Marker "From $SHA1 $magic_timestamp" die Zeilen From: und Date: aus der Patch-Datei weglassen. Der Titel des Patches weicht wahrscheinlich vom Betreff der Diskussion ab, auf die der Patch antwortet, daher möchten Sie wahrscheinlich die Betreffzeile beibehalten, wie im obigen Beispiel.

Prüfung auf Patch-Beschädigung

Viele Mailer beschädigen, wenn sie nicht richtig konfiguriert sind, Leerzeichen. Hier sind zwei gängige Arten von Beschädigungen:

  • Leere Kontextzeilen, die keine Leerzeichen enthalten.

  • Nicht leere Kontextzeilen, die ein zusätzliches Leerzeichen am Anfang haben.

Eine Möglichkeit, zu testen, ob Ihr MUA richtig eingerichtet ist, ist:

  • Senden Sie sich den Patch selbst, genau so, wie Sie es tun würden, außer mit To:- und Cc:-Zeilen, die nicht die Listen- und Maintainer-Adresse enthalten.

  • Speichern Sie diesen Patch in einer Datei im UNIX-Mailbox-Format. Nennen Sie sie zum Beispiel a.patch.

  • Wenden Sie ihn an

    $ git fetch <project> master:test-apply
$ git switch test-apply
$ git restore --source=HEAD --staged --worktree :/
$ git am a.patch

Wenn er nicht korrekt angewendet wird, kann es verschiedene Gründe geben.

  • Der Patch selbst lässt sich nicht sauber anwenden. Das ist schlecht, hat aber wenig mit Ihrem MUA zu tun. Sie könnten den Patch mit git-rebase[1] neu basisen, bevor Sie ihn in diesem Fall neu generieren.

  • Der MUA hat Ihren Patch beschädigt; "am" würde sich beschweren, dass der Patch nicht angewendet werden kann. Schauen Sie in das Unterverzeichnis .git/rebase-apply/ und sehen Sie, was die patch-Datei enthält, und prüfen Sie auf die oben genannten gängigen Beschädigungsmuster.

  • Überprüfen Sie dabei auch die info- und final-commit-Dateien. Wenn das, was in final-commit steht, nicht genau dem entspricht, was Sie in der Commit-Log-Nachricht sehen möchten, wird der Empfänger höchstwahrscheinlich die Log-Nachricht beim Anwenden Ihres Patches manuell bearbeiten. Dinge wie "Hi, this is my first patch.\n" in der Patch-E-Mail sollten nach der Dreistrich-Linie kommen, die das Ende der Commit-Nachricht signalisiert.

MUA-SPEZIFISCHE HINWEISE

Hier sind einige Hinweise, wie Sie Patches inline mit verschiedenen Mailern erfolgreich einreichen können.

GMail

GMail bietet keine Möglichkeit, Zeilenumbrüche in der Weboberfläche zu deaktivieren, daher wird es alle von Ihnen gesendeten E-Mails verändern. Sie können jedoch "git send-email" verwenden und Ihre Patches über den GMail SMTP-Server versenden, oder einen beliebigen IMAP-E-Mail-Client verwenden, um sich mit dem Google IMAP-Server zu verbinden und die E-Mails darüber weiterzuleiten.

Hinweise zur Verwendung von git send-email, um Ihre Patches über den GMail SMTP-Server zu versenden, finden Sie im ABSCHNITT BEISPIEL von git-send-email[1].

Hinweise zur Einreichung über die IMAP-Schnittstelle finden Sie im ABSCHNITT BEISPIEL von git-imap-send[1].

Thunderbird

Standardmäßig wickelt Thunderbird E-Mails ab und kennzeichnet sie als format=flowed, beides macht die resultierende E-Mail für Git unbrauchbar.

Es gibt drei verschiedene Ansätze: Verwenden Sie ein Add-on, um Zeilenumbrüche zu deaktivieren, konfigurieren Sie Thunderbird so, dass es keine Patches verändert, oder verwenden Sie einen externen Editor, um Thunderbird davon abzuhalten, die Patches zu verändern.

Ansatz #1 (Add-on)

Installieren Sie das Add-on Toggle Line Wrap, das unter https://addons.thunderbird.net/thunderbird/addon/toggle-line-wrap verfügbar ist. Es fügt einen Button "Line Wrap" zur Symbolleiste des Verfassers hinzu, den Sie anklicken können. Nun können Sie die Nachricht wie gewohnt verfassen (Copy & Paste, git format-patch | git imap-send, etc.), aber Sie müssen Zeilenumbrüche manuell in jeden von Ihnen eingegebenen Text einfügen.

Als Bonusfunktion kann das Add-on Patch-Text im Verfasser erkennen und warnt, wenn die Zeilenumbrüche noch nicht deaktiviert wurden.

Das Add-on erfordert einige Anpassungen der erweiterten Konfiguration (about:config). Diese sind auf der Download-Seite aufgeführt.

Ansatz #2 (Konfiguration)

Drei Schritte

  1. Konfigurieren Sie Ihre Mailserver-Komposition als reinen Text: Bearbeiten...Kontoeinstellungen...Komposition & Adressierung, deaktivieren Sie "Nachrichten in HTML verfassen".

  2. Konfigurieren Sie Ihr allgemeines Kompositionsfenster so, dass es nicht umbricht.

    In Thunderbird 2: Bearbeiten..Voreinstellungen..Komposition, reinen Text auf 0 umbrechen.

    In Thunderbird 3: Bearbeiten..Voreinstellungen..Erweitert..Konfigurations-Editor. Suchen Sie nach "mail.wrap_long_lines". Schalten Sie es um, um sicherzustellen, dass es auf false gesetzt ist. Suchen Sie außerdem nach "mailnews.wraplength" und setzen Sie den Wert auf 0.

  3. Deaktivieren Sie die Verwendung von format=flowed: Bearbeiten..Voreinstellungen..Erweitert..Konfigurations-Editor. Suchen Sie nach "mailnews.send_plaintext_flowed". Schalten Sie es um, um sicherzustellen, dass es auf false gesetzt ist.

Danach sollten Sie E-Mails wie gewohnt verfassen können (Copy & Paste, git format-patch | git imap-send, etc.), und die Patches werden nicht verändert.

Ansatz #3 (Externer Editor)

Die folgenden Thunderbird-Erweiterungen sind erforderlich: AboutConfig von https://mjg.github.io/AboutConfig/ und External Editor von https://globs.org/articles.php?lng=en&pg=8

  1. Bereiten Sie den Patch als Textdatei mit Ihrer bevorzugten Methode vor.

  2. Bevor Sie ein Verfassungsfenster öffnen, verwenden Sie Bearbeiten→Kontoeinstellungen, um die Einstellung "Nachrichten im HTML-Format verfassen" im Panel "Komposition & Adressierung" des zu verwendenden Kontos zu deaktivieren.

  3. Im Hauptfenster von Thunderbird, bevor Sie das Verfassungsfenster für den Patch öffnen, verwenden Sie Werkzeuge→about:config, um die folgenden Einstellungen auf die angegebenen Werte zu setzen:

    	mailnews.send_plaintext_flowed  => false
	mailnews.wraplength             => 0

  4. Öffnen Sie ein Verfassungsfenster und klicken Sie auf das Symbol für den externen Editor.

  5. Lesen Sie in dem externen Editorfenster die Patch-Datei ein und beenden Sie den Editor normal.

Seitenbemerkung: Möglicherweise ist es möglich, Schritt 2 mit about:config und den folgenden Einstellungen durchzuführen, aber bisher hat das niemand ausprobiert.

	mail.html_compose                       => false
	mail.identity.default.compose_html      => false
	mail.identity.id?.compose_html          => false

Es gibt ein Skript in contrib/thunderbird-patch-inline, das Ihnen helfen kann, Patches einfach mit Thunderbird einzufügen. Um es zu verwenden, führen Sie die obigen Schritte aus und verwenden Sie dann das Skript als externen Editor.

KMail

Dies sollte Ihnen helfen, Patches inline mit KMail einzureichen.

  1. Bereiten Sie den Patch als Textdatei vor.

  2. Klicken Sie auf Neue Mail.

  3. Gehen Sie unter "Optionen" im Kompositionsfenster und stellen Sie sicher, dass "Zeilenumbruch" nicht aktiviert ist.

  4. Verwenden Sie Nachricht → Datei einfügen… und fügen Sie den Patch ein.

  5. Zurück im Kompositionsfenster: Fügen Sie beliebigen weiteren Text zur Nachricht hinzu, vervollständigen Sie die Adressierungs- und Betreffzeilen und drücken Sie Senden.

BASIS-TREE-INFORMATIONEN

Der Basis-Tree-Informationsblock dient dazu, Maintainern oder externen Testern das genaue Zustand zu vermitteln, auf den die Patch-Serie angewendet wird. Er besteht aus dem Basis-Commit, einem bekannten Commit, der Teil der stabilen Projektgeschichte ist, auf der alle anderen aufbauen, und null oder mehr vorausgesetzten Patches, die bekannte Patches in Bearbeitung sind, aber noch nicht Teil des Basis-Commits sind und die in topologischer Reihenfolge auf dem Basis-Commit angewendet werden müssen, bevor die Patches angewendet werden können.

Der Basis-Commit wird als "base-commit: " gefolgt von der 40-stelligen Hexadezimalzahl des Commit-Objektnamens angezeigt. Ein vorausgesetzter Patch wird als "prerequisite-patch-id: " gefolgt von der 40-stelligen Hexadezimalzahl der Patch-ID angezeigt, die durch Übergabe des Patches an den Befehl git patch-id --stable erhalten werden kann.

Stellen Sie sich vor, dass auf dem öffentlichen Commit P die bekannten Patches X, Y und Z von jemand anderem angewendet wurden und dann Ihre dreiteilige Patch-Serie A, B, C erstellt wurde. Die Historie würde so aussehen:

---P---X---Y---Z---A---B---C

Mit git format-patch --base=P -3 C (oder Varianten davon, z. B. mit --cover-letter oder unter Verwendung von Z..C anstelle von -3 C zur Angabe des Bereichs) wird der Basis-Tree-Informationsblock am Ende der ersten vom Befehl ausgegebenen Nachricht angezeigt (entweder der erste Patch oder das Anschreiben), wie folgt:

base-commit: P
prerequisite-patch-id: X
prerequisite-patch-id: Y
prerequisite-patch-id: Z

Für nicht-lineare Topologien, wie z.B.:

---P---X---A---M---C
    \         /
     Y---Z---B

Sie können auch git format-patch --base=P -3 C verwenden, um Patches für A, B und C zu generieren, und die Identifikatoren für P, X, Y, Z werden am Ende der ersten Nachricht angehängt.

Wenn --base=auto auf der Kommandozeile gesetzt ist, wird der Basis-Commit automatisch als Merge-Basis des Tip-Commits des Remote-Tracking-Branches und des auf der Kommandozeile angegebenen Revisionsbereichs berechnet. Für einen lokalen Branch müssen Sie ihn mit git branch --set-upstream-to zu einem Remote-Branch machen, bevor Sie diese Option verwenden.

BEISPIELE

  • Extrahieren Sie Commits zwischen den Revisionen R1 und R2 und wenden Sie sie mit git am auf den aktuellen Branch an, um sie auszuwählen.

    $ git format-patch -k --stdout R1..R2 | git am -3 -k

  • Extrahieren Sie alle Commits, die im aktuellen Branch, aber nicht im Origin-Branch vorhanden sind.

    $ git format-patch origin

    Für jeden Commit wird eine separate Datei im aktuellen Verzeichnis erstellt.

  • Extrahieren Sie alle Commits, die seit Projektbeginn zu origin führen.

    $ git format-patch --root origin

  • Dasselbe wie im vorherigen Beispiel.

    $ git format-patch -M -B origin

    Zusätzlich erkennt und behandelt es Renames und vollständige Rewrites intelligent, um einen Umbenennungs-Patch zu erzeugen. Ein Umbenennungs-Patch reduziert die Textmenge und macht ihn im Allgemeinen leichter zu überprüfen. Beachten Sie, dass Nicht-Git-"patch"-Programme Umbenennungs-Patches nicht verstehen, also verwenden Sie ihn nur, wenn Sie wissen, dass der Empfänger Git zum Anwenden Ihres Patches verwendet.

  • Extrahieren Sie die drei obersten Commits aus dem aktuellen Branch und formatieren Sie sie als E-Mail-fähige Patches.

    $ git format-patch -3

HINWEISE

Beachten Sie, dass format-patch Merge-Commits aus der Ausgabe weglässt, auch wenn sie Teil des angeforderten Bereichs sind. Ein einfacher "Patch" enthält nicht genügend Informationen, damit der Empfänger denselben Merge-Commit reproduzieren kann.

SIEHE AUCH

git-am[1], git-send-email[1]

GIT

Teil der git[1] Suite