Die Daten, die dem Schlüsselwort gitdir und einem Doppelpunkt folgen, werden als Glob-Muster verwendet. Wenn der Speicherort des .git-Verzeichnisses mit dem Muster übereinstimmt, ist die Include-Bedingung erfüllt.

Dies ist dasselbe wie gitdir, mit der Ausnahme, dass die Übereinstimmung case-insensitiv erfolgt (z. B. auf case-insensitiven Dateisystemen).

Die Daten, die dem Schlüsselwort onbranch und einem Doppelpunkt folgen, werden als Muster mit Standard-Globbing-Wildcards und zwei zusätzlichen, **/ und /**, interpretiert, die mehrere Pfadkomponenten abgleichen können. Wenn wir uns in einem Worktree befinden, dessen Name des aktuell ausgecheckten Branches mit dem Muster übereinstimmt, ist die Include-Bedingung erfüllt.

Die Daten, die diesem Schlüsselwort und einem Doppelpunkt folgen, werden als Muster mit Standard-Globbing-Wildcards und zwei zusätzlichen, **/ und /**, interpretiert, die mehrere Komponenten abgleichen können. Beim ersten Auftreten dieses Schlüsselworts werden die restlichen Konfigurationsdateien nach Remote-URLs durchsucht (ohne Werte anzuwenden). Wenn mindestens eine Remote-URL existiert, die mit diesem Muster übereinstimmt, ist die Include-Bedingung erfüllt.

Wenn eine Variable angibt, einen booleschen Wert anzunehmen, werden viele Synonyme für true und false akzeptiert; diese sind alle case-insensitiv.

Der Wert vieler Variablen, die verschiedene Größen angeben, kann mit k, M,…​ enden, um "skaliere die Zahl um 1024", "um 1024x1024" usw. zu bedeuten.

Der Wert einer Variablen, die eine Farbe annimmt, ist eine Liste von Farben (höchstens zwei, eine für Vordergrund und eine für Hintergrund) und Attributen (beliebige Anzahl), durch Leerzeichen getrennt.

Eine Variable, die einen Pfadnamenwert annimmt, kann einen String erhalten, der mit "~/" oder "~user/" beginnt, und die übliche Tilde-Expansion wird auf einen solchen String angewendet: ~/ wird zum Wert von $HOME erweitert, und ~user/ zum Home-Verzeichnis des angegebenen Benutzers.

Weist git add an, mit dem Hinzufügen von Dateien fortzufahren, wenn einige Dateien aufgrund von Indexierungsfehlern nicht hinzugefügt werden können. Entspricht der Option --ignore-errors von git-add[1]. add.ignore-errors ist veraltet, da sie nicht der üblichen Namenskonvention für Konfigurationsvariablen folgt.

Diese Variablen steuern verschiedene optionale Hilfemeldungen, die dazu dienen, neue Benutzer zu unterstützen. Wenn sie unkonfiguriert bleiben, gibt Git die Meldung zusammen mit Anweisungen aus, wie sie unterdrückt werden kann. Sie können Git mitteilen, dass Sie das Problem verstanden haben und keine bestimmte Hilfemeldung mehr benötigen, indem Sie die entsprechende Variable auf false setzen.

Befehlsealiase für den Wrapper-Befehl git[1] - z.B. nach der Definition von alias.last = cat-file commit HEAD ist der Aufruf git last äquivalent zu git cat-file commit HEAD. Um Verwechslungen und Probleme bei der Verwendung von Skripten zu vermeiden, werden Aliase, die bestehende Git-Befehle verdecken, ignoriert, mit Ausnahme von veralteten Befehlen. Argumente werden durch Leerzeichen getrennt, die übliche Shell-Quoting und -Escaping werden unterstützt. Ein Paar von Anführungszeichen oder ein Backslash können verwendet werden, um sie zu quoten.

Wenn wahr, ruft git-am git-mailsplit für Patches im mbox-Format mit dem Parameter --keep-cr auf. In diesem Fall wird git-mailsplit \r nicht von Zeilen entfernen, die mit \r\n enden. Kann überschrieben werden, indem --no-keep-cr von der Befehlszeile angegeben wird. Siehe git-am[1], git-mailsplit[1].

Standardmäßig schlägt git am fehl, wenn der Patch nicht sauber angewendet werden kann. Wenn dieser Wert auf true gesetzt ist, weist diese Einstellung git am an, auf einen 3-Wege-Merge zurückzufallen, wenn der Patch die Identität von Blobs aufzeichnet, auf die er angewendet werden soll, und wir diese Blobs lokal verfügbar haben (entspricht der Angabe der Option --3way von der Befehlszeile). Standardmäßig ist dies false. Siehe git-am[1].

Wenn auf change gesetzt, weist es git apply an, Änderungen im Whitespace zu ignorieren, auf die gleiche Weise wie die Option --ignore-space-change. Wenn auf eines der folgenden gesetzt: no, none, never, false, weist es git apply an, alle Whitespace-Unterschiede zu respektieren. Siehe git-apply[1].

Weist git apply an, wie mit Whitespace umgegangen werden soll, auf die gleiche Weise wie die Option --whitespace. Siehe git-apply[1].

Eine Referenz auf einen Baum im Repository, aus dem Attribute gelesen werden sollen, anstelle der Datei .gitattributes im Arbeitsbaum. Wenn der Wert nicht zu einem gültigen Baum-Objekt aufgelöst werden kann, wird stattdessen ein leerer Baum verwendet. Wenn die Umgebungsvariable GIT_ATTR_SOURCE oder die Befehlszeilenoption --attr-source verwendet wird, hat diese Konfigurationsvariable keine Auswirkung.

Regulärer Ausdruck, der zur Übereinstimmung von Referenznamen verwendet wird. Commits, auf die von Referenzen gezeigt wird, die diesem Muster entsprechen (und die unten genannten Kriterien erfüllen, wie z.B. bitmapPseudoMerge.<name>.sampleRate und bitmapPseudoMerge.<name>.threshold), werden für die Aufnahme in eine Pseudo-Merge-Bitmap berücksichtigt.

Bestimmt die Rate, mit der aufeinanderfolgende Pseudo-Merge-Bitmap-Gruppen kleiner werden. Muss nicht-negativ sein. Dieser Parameter kann als k in der Funktion f(n) = C * n^-k betrachtet werden, wobei f(n) die Größe der `n`-ten Gruppe ist.

Bestimmt den Anteil der nicht-bitmappten Commits (unter Referenzspitzen), die für die Aufnahme in eine instabile Pseudo-Merge-Bitmap ausgewählt werden. Muss zwischen 0 und 1 (einschließlich) liegen. Standardmäßig ist dies 1.

Bestimmt das Mindestalter von nicht-bitmappten Commits (unter Referenzspitzen, wie oben), die für die Aufnahme in eine instabile Pseudo-Merge-Bitmap in Frage kommen. Standardmäßig ist dies 1.week.ago.

Bestimmt die maximale Anzahl von Pseudo-Merge-Commits, unter denen Commits verteilt werden können.

Bestimmt das Mindestalter von Commits (unter Referenzspitzen, wie oben, jedoch werden stabile Commits auch dann als Kandidaten betrachtet, wenn sie von einer Bitmap abgedeckt wurden), die für eine stabile Pseudo-Merge-Bitmap in Frage kommen. Standardmäßig ist dies 1.month.ago.

Bestimmt die Größe (in Anzahl der Commits) einer stabilen Pseudo-Merge-Bitmap. Standardmäßig ist dies 512.

Zeigt einen leeren Commit-Objektnamen für Rand-Commits in git-blame[1] an. Diese Option ist standardmäßig false.

Dies bestimmt das Farbschema, das auf die Ausgabe von blame angewendet wird. Es kann repeatedLines, highlightRecent oder none sein, was der Standardwert ist.

Gibt das Format an, das zur Ausgabe von Daten in git-blame[1] verwendet wird. Wenn nicht gesetzt, wird das ISO-Format verwendet. Für unterstützte Werte siehe die Diskussion der Option --date in git-log[1].

Zeigt die E-Mail-Adresse des Autors anstelle des Namens des Autors in git-blame[1]. Diese Option ist standardmäßig false.

Behandelt keine Root-Commits als Randpunkte in git-blame[1]. Diese Option ist standardmäßig false.

Ignoriert Revisionen, die in der Datei aufgelistet sind, ein undokumentierter Objektname pro Zeile, in git-blame[1]. Leerzeichen und Kommentare, die mit # beginnen, werden ignoriert. Diese Option kann mehrmals wiederholt werden. Leere Dateinamen setzen die Liste der ignorierten Revisionen zurück. Diese Option wird vor der Befehlszeilenoption --ignore-revs-file behandelt.

Markiert Zeilen, die von einer ignorierten Revision geändert wurden, die wir keinem anderen Commit zuordnen konnten, mit einem * in der Ausgabe von git-blame[1].

Markiert Zeilen, die von einer ignorierten Revision geändert wurden, die wir einem anderen Commit zugeordnet haben, mit einem ? in der Ausgabe von git-blame[1].

Weist git branch, git switch und git checkout an, neue Branches so einzurichten, dass git-pull[1] vom Startpunkt-Branch aus ordnungsgemäß zusammengeführt wird. Beachten Sie, dass dieses Verhalten auch dann pro Branch über die Optionen --track und --no-track gewählt werden kann, wenn diese Option nicht gesetzt ist. Diese Option ist standardmäßig auf true gesetzt. Die gültigen Einstellungen sind

Wenn ein neuer Branch mit git branch, git switch oder git checkout erstellt wird, der einen anderen Branch verfolgt, weist diese Variable Git an, Pull so einzurichten, dass stattdessen gerebased wird (siehe branch.<name>.rebase). Die gültigen Einstellungen sind

Diese Variable steuert die Sortierreihenfolge von Branches, wenn sie von git-branch[1] angezeigt werden. Ohne die Option --sort=<value> wird der Wert dieser Variable als Standard verwendet. Siehe git-for-each-ref[1] Feldnamen für gültige Werte.

Wenn sich auf Branch <name>, weist es git fetch und git push an, von welchem Remote abgerufen oder wohin gepusht werden soll. Das Remote zum Pushen kann mit remote.pushDefault (für alle Branches) überschrieben werden. Das Remote zum Pushen für den aktuellen Branch kann weiter mit branch.<name>.pushRemote überschrieben werden. Wenn kein Remote konfiguriert ist oder wenn Sie sich auf keinem Branch befinden und mehr als ein Remote im Repository definiert ist, wird standardmäßig origin für das Abrufen und remote.pushDefault für das Pushen verwendet. Zusätzlich ist . (ein Punkt) das aktuelle lokale Repository (ein Punkt-Repository), siehe branch.<name>.merge's letzter Hinweis unten.

Wenn auf Branch <name>, überschreibt es branch.<name>.remote zum Pushen. Es überschreibt auch remote.pushDefault zum Pushen vom Branch <name>. Wenn Sie von einem Ort abrufen (z.B. Ihrem Upstream) und an einen anderen Ort pushen (z.B. Ihr eigenes Publishing-Repository), möchten Sie remote.pushDefault setzen, um das Remote zum Pushen für alle Branches anzugeben, und diese Option verwenden, um es für einen bestimmten Branch zu überschreiben.

Definiert zusammen mit branch.<name>.remote den Upstream-Branch für den angegebenen Branch. Es sagt git fetch/git pull/git rebase, welcher Branch zusammengeführt werden soll und kann auch git push beeinflussen (siehe push.default). Wenn Sie sich auf Branch <name> befinden, sagt es git fetch den Standard-Refspec, der in FETCH_HEAD zum Zusammenführen markiert werden soll. Der Wert wird wie der Remote-Teil eines Refspecs behandelt und muss einem Ref entsprechen, das vom Remote, das von branch.<name>.remote angegeben wurde, abgerufen wird. Die Merge-Informationen werden von git pull (das zuerst git fetch aufruft) verwendet, um den Standard-Branch für das Zusammenführen nachzuschlagen. Ohne diese Option führt git pull standardmäßig den ersten abgerufenen Refspec zusammen. Geben Sie mehrere Werte an, um einen Oktopus-Merge zu erhalten. Wenn Sie git pull so einrichten möchten, dass er in <name> von einem anderen Branch im lokalen Repository zusammenführt, können Sie branch.<name>.merge auf den gewünschten Branch verweisen lassen und den relativen Pfad . (ein Punkt) für branch.<name>.remote verwenden.

Setzt Standardoptionen für das Zusammenführen in den Branch <name>. Die Syntax und die unterstützten Optionen sind dieselben wie bei git-merge[1], aber Optionen mit Leerzeichen sind derzeit nicht unterstützt.

Wenn wahr, rebased den Branch <name> auf den abgerufenen Branch, anstatt den Standard-Branch vom Standard-Remote zusammenzuführen, wenn git pull ausgeführt wird. Siehe pull.rebase, um dies nicht-branchspezifisch zu tun.

Branch-Beschreibung, kann mit git branch --edit-description bearbeitet werden. Die Branch-Beschreibung wird automatisch dem format-patch-Cover-Letter oder der request-pull-Zusammenfassung hinzugefügt.

Gibt den Befehl zum Aufrufen des angegebenen Browsers an. Der angegebene Befehl wird in der Shell ausgewertet, wobei die URLs als Argumente übergeben werden. (Siehe git-web--browse[1].)

Überschreibt den Pfad für das angegebene Werkzeug, das zum Anzeigen von HTML-Hilfe (siehe Option -w in git-help[1]) oder eines funktionierenden Repositorys in gitweb (siehe git-instaweb[1]) verwendet werden kann.

Die Schlüssel bundle.* können in einer Bundle-Listen-Datei erscheinen, die über die Option git clone --bundle-uri gefunden wird. Diese Schlüssel haben derzeit keine Auswirkungen, wenn sie in einer Repository-Konfigurationsdatei platziert werden, obwohl sich dies in Zukunft ändern wird. Weitere Details finden Sie in des Bundle-URI-Design-Dokuments.

Dieser ganzzahlige Wert gibt die Version des von der Bundle-Liste verwendeten Bundle-Listenformats an. Derzeit ist der einzige akzeptierte Wert 1.

Dieser Zeichenkettenwert sollte entweder all oder any sein. Dieser Wert beschreibt, ob alle beworbenen Bundles erforderlich sind, um ein vollständiges Verständnis der gebündelten Informationen zu entpacken (all) oder ob eine der aufgelisteten Bundle-URIs ausreichend ist (any).

Wenn dieser Schlüssel mit Zeichenkettenwert vorhanden ist, dann ist die Bundle-Liste so konzipiert, dass sie gut mit inkrementellen git fetch-Befehlen funktioniert. Die Heuristik signalisiert, dass für jedes Bundle zusätzliche Schlüssel verfügbar sind, die dem Client helfen zu bestimmen, welche Untermenge von Bundles heruntergeladen werden soll. Der einzige derzeit verstandene Wert ist creationToken.

Die Schlüssel bundle.<id>.* werden verwendet, um ein einzelnes Element in der Bundle-Liste zu beschreiben, das zur Identifizierung unter <id> gruppiert ist.

Dieser Zeichenkettenwert definiert die URI, über die Git auf den Inhalt dieser <id> zugreifen kann. Diese URI kann eine Bundle-Datei oder eine andere Bundle-Liste sein.

Wenn Sie git checkout <etwas> oder git switch <etwas> ausführen und nur ein Remote haben, kann dies implizit auf das Auschecken und Verfolgen von z.B. origin/<etwas> zurückfallen. Dies funktioniert nicht mehr, sobald Sie mehr als ein Remote mit einer <etwas>-Referenz haben. Diese Einstellung ermöglicht es, den Namen eines bevorzugten Remotes festzulegen, das bei der Eindeutigkeitsbestimmung immer Vorrang hat. Der typische Anwendungsfall ist, dies auf origin zu setzen.

Stellt den Standardwert für die Option --guess oder --no-guess in git checkout und git switch bereit. Siehe git-switch[1] und git-checkout[1].

Die Anzahl der parallelen Worker, die beim Aktualisieren des Arbeitsbaums verwendet werden. Standardmäßig ist dies eins, d.h. sequenzielle Ausführung. Wenn auf einen Wert kleiner als eins gesetzt, verwendet Git so viele Worker wie die Anzahl der verfügbaren logischen Kerne. Diese Einstellung und checkout.thresholdForParallelism wirken sich auf alle Befehle aus, die einen Checkout durchführen. Z.B. checkout, clone, reset, sparse-checkout usw.

Beim parallelen Checkout mit einer kleinen Anzahl von Dateien können die Kosten für das Erzeugen von Subprozessen und die Interprozesskommunikation die Vorteile der Parallelisierung überwiegen. Diese Einstellung ermöglicht es Ihnen, die Mindestanzahl von Dateien festzulegen, für die ein paralleler Checkout versucht werden soll. Standardmäßig ist dies 100.

Ein boolescher Wert, der git-clean dazu bringt, die Löschung von Dateien zu verweigern, es sei denn, -f wird angegeben. Standardmäßig true.

Der Name des Remotes, das beim Klonen eines Repositorys erstellt werden soll. Standardmäßig origin. Er kann durch Angabe der Befehlszeilenoption --origin für git-clone[1] überschrieben werden.

Verhindert das Klonen eines Repositorys, wenn es flach ist. Dies kann durch Angabe der Option --reject-shallow auf der Befehlszeile überschrieben werden. Siehe git-clone[1].

Wenn ein Filter für teilweises Klonen angegeben wird (siehe --filter in git-rev-list[1]) und --recurse-submodules verwendet wird, wird der Filter auch auf Submodule angewendet.

Ein boolescher Wert, um Farben in Hinweisen zu aktivieren/deaktivieren (z.B. wenn ein Push fehlschlug, siehe advice.* für eine Liste). Kann auf always, false (oder never) oder auto (oder true) gesetzt werden, wobei Farben nur verwendet werden, wenn die Fehlerausgabe an ein Terminal geht. Wenn nicht gesetzt, wird der Wert von color.ui verwendet (auto ist Standard).

Verwendet angepasste Farben für Hinweise.

Gibt die Linien-Annotation-Farbe für git blame --color-by-age an, abhängig vom Alter der Linie.

Verwendet die angegebene Farbe, um Linienannotationen für git blame --color-lines zu kolorieren, wenn sie vom selben Commit wie die vorherige Zeile stammen. Standardmäßig cyan.

Ein boolescher Wert, um Farbe in der Ausgabe von git-branch[1] zu aktivieren/deaktivieren. Kann auf always, false (oder never) oder auto (oder true) gesetzt werden, wobei Farben nur verwendet werden, wenn die Ausgabe an ein Terminal geht. Wenn nicht gesetzt, wird der Wert von color.ui verwendet (auto ist Standard).

Verwendet angepasste Farbe für die Branch-Kolorierung. <slot> ist einer von current (der aktuelle Branch), local (ein lokaler Branch), remote (ein Remote-Tracking-Branch in refs/remotes/), upstream (Upstream-Tracking-Branch), plain (andere Refs).

Ob ANSI-Escape-Sequenzen verwendet werden sollen, um Patches farbig darzustellen. Wenn dies auf always gesetzt ist, verwenden git-diff[1], git-log[1] und git-show[1] Farben für alle Patches. Wenn es auf true oder auto gesetzt ist, verwenden diese Befehle Farben nur, wenn die Ausgabe an das Terminal erfolgt. Wenn nicht gesetzt, wird der Wert von color.ui verwendet (auto ist Standard).

Verwenden Sie angepasste Farben für die Diff-Kolorierung. <slot> gibt an, welcher Teil des Patches die angegebene Farbe verwenden soll, und ist einer von context (Kontexttext – plain ist ein historisches Synonym), meta (Metainformationen), frag (Hunk-Header), func (Funktion im Hunk-Header), old (entfernte Zeilen), new (hinzugefügte Zeilen), commit (Commit-Header), whitespace (Hervorhebung von Whitespace-Fehlern), oldMoved (gelöschte Zeilen), newMoved (hinzugefügte Zeilen), oldMovedDimmed, oldMovedAlternative, oldMovedAlternativeDimmed, newMovedDimmed, newMovedAlternative newMovedAlternativeDimmed (Details finden Sie in der Einstellung <mode> von --color-moved in git-diff[1]), contextDimmed, oldDimmed, newDimmed, contextBold, oldBold und newBold (Details finden Sie in git-range-diff[1]).

Verwenden Sie angepasste Farben für die Ausgabe von git log --decorate. <slot> ist einer von branch, remoteBranch, tag, stash oder HEAD für lokale Zweige, Remote-Tracking-Zweige, Tags, Stash bzw. HEAD und grafted für veredelte Commits.

Wenn auf always gesetzt, werden Übereinstimmungen immer hervorgehoben. Wenn false (oder never), niemals. Wenn auf true oder auto gesetzt, wird Farbe nur verwendet, wenn die Ausgabe auf das Terminal geschrieben wird. Wenn nicht gesetzt, wird der Wert von color.ui verwendet (auto als Standard).

Verwenden Sie angepasste Farben für die Grep-Kolorierung. <slot> gibt an, welcher Teil der Zeile die angegebene Farbe verwenden soll, und ist einer von

Wenn auf always gesetzt, werden interaktive Aufforderungen und Anzeigen (wie die von "git-add --interactive" und "git-clean --interactive" verwendeten) immer farblich hervorgehoben. Wenn falsch (oder never), niemals. Wenn auf true oder auto gesetzt, wird Farbe nur verwendet, wenn die Ausgabe auf das Terminal erfolgt. Wenn nicht gesetzt, wird der Wert von color.ui verwendet (auto als Standard).

Verwenden Sie angepasste Farben für die Ausgabe von git add --interactive und git clean --interactive. <slot> kann prompt, header, help oder error sein, für vier verschiedene Arten von normaler Ausgabe von interaktiven Befehlen.

Ein boolescher Wert, der angibt, ob die Modi mit Farb-Auto-Einstellung die Ausgabe an den Pager kolorieren sollen. Standard ist true; setzen Sie diesen Wert auf false, wenn Ihr Pager keine ANSI-Farbcodes versteht.

Ein boolescher Wert, um Farben in Push-Fehlermeldungen zu aktivieren/deaktivieren. Kann auf always, false (oder never) oder auto (oder true) gesetzt werden. In diesem Fall werden Farben nur verwendet, wenn die Fehlerausgabe an ein Terminal erfolgt. Wenn nicht gesetzt, wird der Wert von color.ui verwendet (auto als Standard).

Verwenden Sie eine angepasste Farbe für Push-Fehler.

Wenn gesetzt, werden Schlüsselwörter am Anfang der Zeile hervorgehoben. Die Schlüsselwörter sind "error", "warning", "hint" und "success" und werden nicht fallweise behandelt. Kann auf always, false (oder never) oder auto (oder true) gesetzt werden. Wenn nicht gesetzt, wird der Wert von color.ui verwendet (auto als Standard).

Verwenden Sie eine angepasste Farbe für jedes Remote-Schlüsselwort. <slot> kann hint, warning, success oder error sein, die den entsprechenden Schlüsselwörtern entsprechen.

Ein boolescher Wert, um Farbe in der Ausgabe von git-show-branch[1] zu aktivieren/deaktivieren. Kann auf always, false (oder never) oder auto (oder true) gesetzt werden. In diesem Fall werden Farben nur verwendet, wenn die Ausgabe auf ein Terminal erfolgt. Wenn nicht gesetzt, wird der Wert von color.ui verwendet (auto als Standard).

Ein boolescher Wert, um Farbe in der Ausgabe von git-status[1] zu aktivieren/deaktivieren. Kann auf always, false (oder never) oder auto (oder true) gesetzt werden. In diesem Fall werden Farben nur verwendet, wenn die Ausgabe auf ein Terminal erfolgt. Wenn nicht gesetzt, wird der Wert von color.ui verwendet (auto als Standard).

Verwenden Sie eine angepasste Farbe für die Status-Kolorierung. <slot> ist einer von header (der Header-Text der Statusmeldung), added oder updated (Dateien, die hinzugefügt, aber nicht committet wurden), changed (Dateien, die geändert, aber nicht im Index hinzugefügt wurden), untracked (Dateien, die von Git nicht verfolgt werden), branch (der aktuelle Zweig), nobranch (die Farbe, in der die Warnung *no branch* angezeigt wird, standardmäßig rot), localBranch oder remoteBranch (die lokalen und Remote-Zweig-Namen, bzw. wenn Zweig- und Tracking-Informationen im Kurzformat des Status angezeigt werden) oder unmerged (Dateien mit nicht zusammengeführten Änderungen).

Ein boolescher Wert, um Farbe bei abgelehnten Pushes zu aktivieren/deaktivieren. Kann auf always, false (oder never) oder auto (oder true) gesetzt werden. In diesem Fall werden Farben nur verwendet, wenn die Fehlerausgabe an ein Terminal erfolgt. Wenn nicht gesetzt, wird der Wert von color.ui verwendet (auto als Standard).

Verwenden Sie eine angepasste Farbe, wenn ein Push abgelehnt wurde.

Diese Variable bestimmt den Standardwert für Variablen wie color.diff und color.grep, die die Verwendung von Farben pro Befehlsfamilie steuern. Ihr Geltungsbereich wird erweitert, wenn weitere Befehle Konfigurationen für die Einstellung eines Standardwerts für die Option --color erhalten. Setzen Sie sie auf false oder never, wenn Git-Befehle keine Farbe verwenden sollen, es sei denn, sie werden explizit mit einer anderen Konfiguration oder der Option --color aktiviert. Setzen Sie sie auf always, wenn Sie möchten, dass alle Ausgaben, die nicht für die maschinelle Verarbeitung bestimmt sind, Farbe verwenden. Setzen Sie sie auf true oder auto (dies ist seit Git 1.8.4 der Standard), wenn Sie möchten, dass solche Ausgaben Farbe verwenden, wenn sie auf das Terminal geschrieben werden.

Gibt an, ob unterstützte Befehle in Spalten ausgeben sollen. Diese Variable besteht aus einer Liste von durch Leerzeichen oder Kommas getrennten Token.

Gibt an, ob die Zweigliste in git branch in Spalten ausgegeben werden soll. Details siehe column.ui.

Gibt das Layout beim Auflisten von Elementen in git clean -i an, das Dateien und Verzeichnisse immer in Spalten anzeigt. Details siehe column.ui.

Gibt an, ob unverfolgte Dateien in git status in Spalten ausgegeben werden sollen. Details siehe column.ui.

Gibt an, ob Tag-Listen in git tag in Spalten ausgegeben werden sollen. Details siehe column.ui.

Diese Einstellung überschreibt den Standardwert der Option --cleanup in git commit. Details siehe git-commit[1]. Das Ändern des Standardwerts kann nützlich sein, wenn Sie Zeilen, die mit dem Kommentarzeichen beginnen (core.commentChar, Standard #), in Ihrer Log-Nachricht immer beibehalten möchten. In diesem Fall würden Sie git config commit.cleanup whitespace ausführen (beachten Sie, dass Sie die Hilfezeilen, die mit dem Kommentarzeichen beginnen, in der Commit-Log-Vorlage selbst entfernen müssen, wenn Sie dies tun).

Ein boolescher Wert, der angibt, ob alle Commits GPG-signiert werden sollen. Die Verwendung dieser Option bei Vorgängen wie Rebase kann dazu führen, dass eine große Anzahl von Commits signiert wird. Es kann praktisch sein, einen Agenten zu verwenden, um die Eingabe Ihrer GPG-Passphrase mehrmals zu vermeiden.

Ein boolescher Wert, um die Einbeziehung von Statusinformationen in die Commit-Nachrichten-Vorlage beim Verwenden eines Editors zur Vorbereitung der Commit-Nachricht zu aktivieren/deaktivieren. Standard ist true.

Gibt den Pfadnamen einer Datei an, die als Vorlage für neue Commit-Nachrichten verwendet werden soll.

Ein boolescher Wert oder eine Ganzzahl, um den Grad der Ausführlichkeit bei git commit anzugeben. Details siehe git-commit[1].

Gibt den Typ der zu verwendenden Generierungsnummerversion beim Schreiben oder Lesen der Commit-Graph-Datei an. Wenn Version 1 angegeben ist, werden die korrigierten Commit-Daten nicht geschrieben oder gelesen. Standard ist 2.

Gibt den Standardwert für die Option --max-new-filters von git commit-graph write an (siehe git-commit-graph[1]).

Wenn true, berechnet und schreibt git commit-graph write standardmäßig Bloom-Filter für geänderte Pfade, was dem Übergeben von --changed-paths entspricht. Wenn false oder nicht gesetzt, werden Bloom-Filter für geänderte Pfade während git commit-graph write nur geschrieben, wenn die Filter bereits in der aktuellen Commit-Graph-Datei vorhanden sind. Dies entspricht dem Standardverhalten von git commit-graph write ohne Option --[no-]changed-paths. Um eine Commit-Graph-Datei ohne Filter neu zu schreiben, verwenden Sie die Option --no-changed-paths. Die Befehlszeilenoption --[no-]changed-paths hat immer Vorrang vor dieser Konfiguration. Standard ist nicht gesetzt.

Veraltet. Entspricht `commitGraph.changedPathsVersion=-1` wenn true, und `commitGraph.changedPathsVersion=0` wenn false. (Wenn `commitGraph.changedPathVersion` ebenfalls gesetzt ist, hat `commitGraph.changedPathsVersion` Vorrang.)

Gibt die Version der Bloom-Filter für geänderte Pfade an, die Git lesen und schreiben wird. Kann -1, 0, 1 oder 2 sein. Beachten Sie, dass Versionen größer als 1 mit älteren Git-Versionen, die diese Versionen noch nicht verstehen, inkompatibel sein können. Seien Sie vorsichtig, wenn Sie in einer Umgebung mit gemischten Versionen arbeiten.

Dies wird nur von git-completion.bash verwendet, um Befehle zur Liste der vervollständigten Befehle hinzuzufügen oder daraus zu entfernen. Normalerweise werden nur Porcelain-Befehle und einige ausgewählte andere vervollständigt. Sie können weitere Befehle, durch Leerzeichen getrennt, in dieser Variablen hinzufügen. Das Präfixieren des Befehls mit - entfernt ihn aus der vorhandenen Liste.

Teilt Git mit, ob die Ausführungsberechtigung von Dateien im Arbeitsverzeichnis beachtet werden soll.

(Nur Windows) Wenn true, werden neu erstellte Verzeichnisse und Dateien, deren Name mit einem Punkt beginnt, als versteckt markiert. Wenn dotGitOnly, wird nur das Verzeichnis .git/ versteckt, aber keine anderen Dateien, die mit einem Punkt beginnen. Der Standardmodus ist dotGitOnly.

Interne Variable, die verschiedene Workarounds aktiviert, um Git die bessere Arbeit auf Dateisystemen zu ermöglichen, die nicht case-sensitiv sind, wie APFS, HFS+, FAT, NTFS usw. Wenn beispielsweise eine Verzeichnisauflistung "makefile" findet, wenn Git "Makefile" erwartet, geht Git davon aus, dass es sich um dieselbe Datei handelt und merkt sie sich weiterhin als "Makefile".

Diese Option wird nur von der Mac OS-Implementierung von Git verwendet. Wenn core.precomposeUnicode=true, kehrt Git die Unicode-Zerlegung von Dateinamen, die von Mac OS durchgeführt wird, um. Dies ist nützlich, wenn Sie ein Repository zwischen Mac OS und Linux oder Windows teilen. (Git für Windows 1.7.10 oder höher ist erforderlich, oder Git unter Cygwin 1.7). Wenn false, werden Dateinamen von Git vollständig transparent behandelt, was mit älteren Git-Versionen abwärtskompatibel ist.

Wenn auf true gesetzt, werden keine Pfade ausgecheckt, die auf einem HFS+-Dateisystem als äquivalent zu .git betrachtet würden. Standard ist true unter Mac OS und false überall sonst.

Wenn auf true gesetzt, werden keine Pfade ausgecheckt, die Probleme mit dem NTFS-Dateisystem verursachen würden, z. B. Konflikte mit 8.3 "kurzen" Namen. Standard ist true unter Windows und false überall sonst.

Wenn auf true gesetzt, wird der integrierte Dateisystemüberwachungsdaemon für dieses Arbeitsverzeichnis aktiviert (git-fsmonitor--daemon[1]).

Legt die zu verwendende Protokollversion beim Aufrufen des "fsmonitor"-Hooks fest.

Wenn false, werden die ctime-Unterschiede zwischen dem Index und dem Arbeitsverzeichnis ignoriert; nützlich, wenn die Inode-Änderungszeit regelmäßig von etwas außerhalb von Git geändert wird (Dateisystem-Crawler und einige Backup-Systeme). Siehe git-update-index[1]. Standardmäßig true.

Wenn true, wird die Split-Index-Funktion des Index verwendet. Siehe git-update-index[1]. Standardmäßig false.

Bestimmt, was mit der Funktion des Caches für unverfolgte Dateien des Index geschehen soll. Er wird beibehalten, wenn diese Variable nicht gesetzt oder auf keep gesetzt ist. Er wird automatisch hinzugefügt, wenn er auf true gesetzt ist. Und er wird automatisch entfernt, wenn er auf false gesetzt ist. Bevor Sie ihn auf true setzen, sollten Sie prüfen, ob mtime auf Ihrem System ordnungsgemäß funktioniert. Siehe git-update-index[1]. Standardmäßig keep, es sei denn, feature.manyFiles ist aktiviert, was diese Einstellung standardmäßig auf true setzt.

Wenn fehlend oder auf default gesetzt, werden viele Felder in der Stat-Struktur überprüft, um zu erkennen, ob eine Datei geändert wurde, seit Git sie betrachtet hat. Wenn diese Konfigurationsvariable auf minimal gesetzt ist, werden der Subsekundenanteil von mtime und ctime, die uid und gid des Eigentümers der Datei, die Inode-Nummer (und die Gerätenummer, wenn Git so kompiliert wurde, dass es sie verwendet) aus der Überprüfung dieser Felder ausgeschlossen, sodass nur der Ganzsekundenanteil von mtime (und ctime, wenn core.trustCtime gesetzt ist) und die Dateigröße überprüft werden.

Befehle, die Pfade ausgeben (z. B. ls-files, diff), quotieren "ungewöhnliche" Zeichen im Pfadnamen, indem sie den Pfadnamen in doppelte Anführungszeichen setzen und diese Zeichen mit Backslashes escapen, ähnlich wie C Steuerzeichen (z. B. \t für TAB, \n für LF, \\ für Backslash) oder Bytes mit Werten größer als 0x80 (z. B. oktal \302\265 für "Mikro" in UTF-8) escapen. Wenn diese Variable auf false gesetzt ist, werden Bytes höher als 0x80 nicht mehr als "ungewöhnlich" betrachtet. Doppelte Anführungszeichen, Backslashes und Steuerzeichen werden immer escapet, unabhängig von der Einstellung dieser Variable. Ein einfaches Leerzeichen wird nicht als "ungewöhnlich" betrachtet. Viele Befehle können Pfadnamen mit der Option -z vollständig unverändert ausgeben. Der Standardwert ist true.

Legt den Zeilenumbruchtyp fest, der im Arbeitsverzeichnis für Dateien verwendet werden soll, die als Text markiert sind (entweder durch Setzen des Attributs text oder durch text=auto und automatische Erkennung des Inhalts als Text durch Git). Alternativen sind lf, crlf und native, das den nativen Zeilenumbruch der Plattform verwendet. Der Standardwert ist native. Weitere Informationen zur Konvertierung von Zeilenumbrüchen finden Sie in gitattributes[5]. Beachten Sie, dass dieser Wert ignoriert wird, wenn core.autocrlf auf true oder input gesetzt ist.

Wenn true, wird Git überprüfen, ob die Konvertierung von CRLF umkehrbar ist, wenn die Konvertierung von Zeilenumbrüchen aktiv ist. Git prüft, ob ein Befehl eine Datei im Arbeitsverzeichnis entweder direkt oder indirekt modifiziert. Zum Beispiel sollte das Committen einer Datei, gefolgt vom Auschecken derselben Datei, zur ursprünglichen Datei im Arbeitsverzeichnis führen. Wenn dies für die aktuelle Einstellung von core.autocrlf nicht der Fall ist, wird Git die Datei ablehnen. Die Variable kann auf "warn" gesetzt werden, in diesem Fall wird Git nur eine Warnung über eine irreversible Konvertierung ausgeben, aber den Vorgang fortsetzen.

Das Setzen dieser Variable auf "true" ist dasselbe wie das Setzen des text-Attributs auf "auto" für alle Dateien und core.eol auf "crlf". Setzen Sie es auf true, wenn Sie CRLF-Zeilenenden in Ihrem Arbeitsverzeichnis haben möchten und das Repository LF-Zeilenenden hat. Diese Variable kann auf input gesetzt werden, in welchem Fall keine Ausgabe-Konvertierung durchgeführt wird.

Eine durch Kommas und/oder Leerzeichen getrennte Liste von Encodings, für die Git UTF-8-Roundtrip-Prüfungen durchführt, wenn sie in einem working-tree-encoding-Attribut verwendet werden (siehe gitattributes[5]). Der Standardwert ist SHIFT-JIS.

Wenn false, werden symbolische Links als kleine Plain-Dateien ausgecheckt, die den Linktext enthalten. git-update-index[1] und git-add[1] ändern den aufgezeichneten Typ nicht in eine reguläre Datei. Nützlich auf Dateisystemen wie FAT, die keine symbolischen Links unterstützen.

Ein "Proxy-Befehl", der ausgeführt wird (als Befehl Host Port) anstelle einer direkten Verbindung zum entfernten Server beim Verwenden des Git-Protokolls zum Abrufen. Wenn der Variablenwert im Format "BEFEHL für DOMAIN" vorliegt, wird der Befehl nur auf Hostnamen angewendet, die mit der angegebenen Domain-Zeichenfolge enden. Diese Variable kann mehrmals gesetzt werden und wird in der angegebenen Reihenfolge abgeglichen; die erste Übereinstimmung gewinnt.

Wenn diese Variable gesetzt ist, verwenden git fetch und git push den angegebenen Befehl anstelle von ssh, wenn sie sich mit einem entfernten System verbinden müssen. Der Befehl hat dasselbe Format wie die Umgebungsvariable GIT_SSH_COMMAND und wird überschrieben, wenn die Umgebungsvariable gesetzt ist.

Wenn true, vermeidet Git das Verwenden von lstat()-Aufrufen, um zu erkennen, ob Dateien geändert wurden, indem das "assume-unchanged"-Bit für die nachverfolgten Dateien gesetzt wird, die sowohl im Index als auch im Arbeitsbaum identisch aktualisiert wurden.

Anstelle des Standardformats "symref" für HEAD und andere symbolische Referenzdateien werden symbolische Links verwendet. Dies ist manchmal erforderlich, um mit alten Skripten zu arbeiten, die erwarten, dass HEAD ein symbolischer Link ist.

Beim Ankündigen von Spitzen verfügbarer Historie von einer Alternative wird die Shell verwendet, um den angegebenen Befehl anstelle von git-for-each-ref[1] auszuführen. Das erste Argument ist der absolute Pfad der Alternative. Die Ausgabe muss eine Hex-Objekt-ID pro Zeile enthalten (d.h. dasselbe wie von git for-each-ref --format='%(objectname) produziert).

Beim Auflisten von Referenzen von einer Alternative werden nur Referenzen aufgelistet, die mit dem angegebenen Präfix beginnen. Präfixe werden abgeglichen, als ob sie als Argumente für git-for-each-ref[1] angegeben wären. Um mehrere Präfixe aufzulisten, trennen Sie sie durch Leerzeichen. Wenn core.alternateRefsCommand gesetzt ist, hat das Setzen von core.alternateRefsPrefixes keine Auswirkung.

Wenn true, wird dieses Repository als *bare* (ohne Arbeitsverzeichnis) angenommen. Wenn dies der Fall ist, werden einige Befehle, die ein Arbeitsverzeichnis benötigen, deaktiviert, wie z.B. git-add[1] oder git-merge[1].

Legt den Pfad zum Stammverzeichnis des Arbeitsbaums fest. Wenn die Umgebungsvariable GIT_COMMON_DIR gesetzt ist, wird core.worktree ignoriert und nicht zur Bestimmung des Stammverzeichnisses des Arbeitsbaums verwendet. Dies kann durch die Umgebungsvariable GIT_WORK_TREE und die Befehlszeilenoption --work-tree überschrieben werden. Der Wert kann ein absoluter Pfad oder relativ zum Pfad zum .git-Verzeichnis sein, der entweder durch --git-dir oder GIT_DIR angegeben oder automatisch ermittelt wird. Wenn --git-dir oder GIT_DIR angegeben ist, aber keine der Optionen --work-tree, GIT_WORK_TREE und core.worktree angegeben ist, wird das aktuelle Arbeitsverzeichnis als oberste Ebene Ihres Arbeitsbaums betrachtet.

Aktiviert das Reflog. Aktualisierungen einer Referenz <ref> werden in die Datei "$GIT_DIR/logs/<ref>" protokolliert, indem die neue und alte SHA-1, Datum/Uhrzeit und der Grund der Aktualisierung angehängt werden, aber nur, wenn die Datei existiert. Wenn diese Konfigurationsvariable auf true gesetzt ist, wird eine fehlende Datei "$GIT_DIR/logs/<ref>" automatisch für Branch-Köpfe (d.h. unter refs/heads/), Remote-Referenzen (d.h. unter refs/remotes/), Note-Referenzen (d.h. unter refs/notes/) und die symbolische Referenz HEAD erstellt. Wenn sie auf always gesetzt ist, wird eine fehlende Reflog automatisch für jede Referenz unter refs/ erstellt.

Interne Variable zur Identifizierung der Repository-Format- und Layoutversion. Siehe gitrepository-layout[5].

Wenn *group* (oder *true*), wird das Repository für mehrere Benutzer in einer Gruppe teilbar gemacht (wodurch sichergestellt wird, dass alle Dateien und Objekte gruppenbeschreibbar sind). Wenn *all* (oder *world* oder *everybody*), ist das Repository für alle Benutzer lesbar, zusätzlich zur Gruppenfreigabe. Wenn *umask* (oder *false*), verwendet Git die vom umask(2) gemeldeten Berechtigungen. Wenn *0xxx*, wobei *0xxx* eine oktale Zahl ist, haben Dateien im Repository diesen Moduswert. *0xxx* überschreibt den umask-Wert des Benutzers (während die anderen Optionen nur angeforderte Teile des umask-Werts des Benutzers überschreiben). Beispiele: *0660* macht das Repo für den Eigentümer und die Gruppe les- und schreibbar, aber für andere unzugänglich (entspricht *group*, es sei denn, umask ist z.B. *0022*). *0640* ist ein Repository, das für die Gruppe lesbar, aber nicht schreibbar ist. Siehe git-init[1]. Standardmäßig false.

Wenn true, wird Git Sie warnen, wenn der von Ihnen übergebene Ref-Name mehrdeutig ist und mehrere Refs im Repository übereinstimmen könnte. Standardmäßig true.

Eine Ganzzahl -1..9, die eine Standard-Kompressionsebene angibt. -1 ist der zlib-Standard. 0 bedeutet keine Kompression, und 1..9 sind verschiedene Geschwindigkeits-/Größen-Trade-offs, wobei 9 die langsamste ist. Wenn gesetzt, liefert dies einen Standard für andere Kompressionsvariablen, wie z.B. core.looseCompression und pack.compression.

Eine Ganzzahl -1..9, die die Kompressionsebene für Objekte angibt, die sich nicht in einer Pack-Datei befinden. -1 ist der zlib-Standard. 0 bedeutet keine Kompression, und 1..9 sind verschiedene Geschwindigkeits-/Größen-Trade-offs, wobei 9 die langsamste ist. Wenn nicht gesetzt, wird standardmäßig core.compression verwendet. Wenn dieses nicht gesetzt ist, wird standardmäßig 1 (beste Geschwindigkeit) verwendet.

Anzahl der Bytes einer Pack-Datei, die in einer einzigen Mapping-Operation in den Speicher gemappt werden. Größere Fenstergrößen können dazu führen, dass Ihr System eine kleinere Anzahl großer Pack-Dateien schneller verarbeitet. Kleinere Fenstergrößen beeinträchtigen die Leistung aufgrund erhöhter Aufrufe des Speichermanagers des Betriebssystems, können aber die Leistung beim Zugriff auf eine große Anzahl großer Pack-Dateien verbessern.

Maximale Anzahl von Bytes, die gleichzeitig aus Pack-Dateien in den Speicher gemappt werden. Wenn Git mehr als diese Anzahl von Bytes gleichzeitig benötigt, um eine Operation abzuschließen, wird es vorhandene Regionen unmappen, um virtuellen Adressraum innerhalb des Prozesses freizugeben.

Maximale Anzahl von Bytes pro Thread, die für das Caching von Basisobjekten reserviert werden, auf die von mehreren deltatisierten Objekten verwiesen werden kann. Durch das Speichern der vollständig dekomprimierten Basisobjekte in einem Cache kann Git das mehrfache Entpacken und Dekomprimieren häufig verwendeter Basisobjekte vermeiden.

Die Größe von Dateien, die als "groß" gelten, was, wie unten diskutiert, das Verhalten zahlreicher Git-Befehle ändert und auch, wie solche Dateien im Repository gespeichert werden. Der Standardwert ist 512 MiB. Gängige Einheiten-Suffixe von *k*, *m* oder *g* werden unterstützt.

Gibt den Pfadnamen zur Datei an, die Muster für Pfade enthält, die nicht nachverfolgt werden sollen, zusätzlich zu .gitignore (pro Verzeichnis) und .git/info/exclude. Standardmäßig $XDG_CONFIG_HOME/git/ignore. Wenn $XDG_CONFIG_HOME weder gesetzt noch leer ist, wird stattdessen $HOME/.config/git/ignore verwendet. Siehe gitignore[5].

Einige Befehle (z.B. svn und http-Schnittstellen), die interaktiv nach einem Passwort fragen, können angewiesen werden, ein externes Programm zu verwenden, das über den Wert dieser Variablen angegeben wird. Kann durch die Umgebungsvariable GIT_ASKPASS überschrieben werden. Wenn nicht gesetzt, wird auf den Wert der Umgebungsvariable SSH_ASKPASS zurückgegriffen oder, falls dies fehlschlägt, auf eine einfache Passwortabfrage. Das externe Programm erhält eine geeignete Eingabeaufforderung als Kommandozeilenargument und schreibt das Passwort auf seine STDOUT.

Zusätzlich zu .gitattributes (pro Verzeichnis) und .git/info/attributes sucht Git in dieser Datei nach Attributen (siehe gitattributes[5]). Pfad-Erweiterungen erfolgen auf die gleiche Weise wie für core.excludesFile. Sein Standardwert ist $XDG_CONFIG_HOME/git/attributes. Wenn $XDG_CONFIG_HOME weder gesetzt noch leer ist, wird stattdessen $HOME/.config/git/attributes verwendet.

Standardmäßig sucht Git nach Hooks im Verzeichnis $GIT_DIR/hooks. Setzen Sie dies auf einen anderen Pfad, z.B. /etc/git/hooks, und Git versucht, Ihre Hooks in diesem Verzeichnis zu finden, z.B. /etc/git/hooks/pre-receive anstelle von $GIT_DIR/hooks/pre-receive.

Befehle wie commit und tag, die es Ihnen ermöglichen, Nachrichten durch Starten eines Editors zu bearbeiten, verwenden den Wert dieser Variablen, wenn sie gesetzt ist und die Umgebungsvariable GIT_EDITOR nicht gesetzt ist. Siehe git-var[1].

Befehle wie commit und tag, die es Ihnen ermöglichen, Nachrichten zu bearbeiten, betrachten eine Zeile, die mit diesem Zeichen beginnt, als auskommentiert und entfernen sie, nachdem der Editor zurückkehrt (Standard *#*).

[core]
# single character for older versions
commentChar = "#"
# string for newer versions (which will override commentChar
# because it comes later in the file)
commentString = "//"

Die Zeitdauer in Millisekunden, die wiederholt versucht wird, eine einzelne Referenz zu sperren. Wert 0 bedeutet, nicht wiederholt zu versuchen; -1 bedeutet, unbegrenzt zu versuchen. Standard ist 100 (d.h. 100 ms Wiederholungsversuch).

Die Zeitdauer in Millisekunden, die wiederholt versucht wird, die Datei packed-refs zu sperren. Wert 0 bedeutet, nicht wiederholt zu versuchen; -1 bedeutet, unbegrenzt zu versuchen. Standard ist 1000 (d.h. 1 Sekunde Wiederholungsversuch).

Text-Viewer, der von Git-Befehlen verwendet wird (z.B. *less*). Der Wert ist für die Interpretation durch die Shell bestimmt. Die Reihenfolge der Präferenz ist die Umgebungsvariable $GIT_PAGER, dann die Konfiguration core.pager, dann $PAGER und dann der bei der Kompilierung ausgewählte Standardwert (normalerweise *less*).

Eine durch Kommas getrennte Liste gängiger Whitespace-Probleme, auf die hingewiesen werden soll. *git diff* verwendet color.diff.whitespace, um sie hervorzuheben, und *git apply --whitespace=error* betrachtet sie als Fehler. Sie können mit einem führenden - einige davon deaktivieren (z.B. *-trailing-space*).

Eine durch Kommas getrennte Liste von Komponenten des Repositorys, die beim Erstellen oder Ändern über core.fsyncMethod gehärtet werden sollen. Sie können die Härtung von Komponenten durch Voranstellen eines - deaktivieren. Nicht gehärtete Elemente können im Falle einer unsauberen Systemabschaltung verloren gehen. Sofern Sie keine speziellen Anforderungen haben, wird empfohlen, diese Option leer zu lassen oder eine der Optionen committed, added oder all zu wählen.

Ein Wert, der die Strategie angibt, die Git zum Härten von Repository-Daten mithilfe von fsync und verwandten Primitiven verwendet.

Dieses Boolean aktiviert fsync() beim Schreiben von Objektdateien. Diese Einstellung ist veraltet. Verwenden Sie stattdessen core.fsync.

Paralleles Vorladen des Index für Operationen wie git diff aktivieren

Nur Windows: Kommagetrennte Liste von Umgebungsvariablennamen, die vor dem Starten eines anderen Prozesses unset werden müssen. Standard ist PERL5LIB, um der Tatsache Rechnung zu tragen, dass Git für Windows auf seinem eigenen Perl-Interpreter besteht.

Sie können dies auf link setzen, in diesem Fall werden ein Hardlink gefolgt von einem Löschen der Quelle verwendet, um sicherzustellen, dass die Objekterstellung keine vorhandenen Objekte überschreibt.

Beim Anzeigen von Commit-Nachrichten werden auch Notizen angezeigt, die in der angegebenen Referenz gespeichert sind. Die Referenz muss vollständig qualifiziert sein. Wenn die angegebene Referenz nicht existiert, ist dies kein Fehler, sondern bedeutet, dass keine Notizen gedruckt werden sollen.

Wenn true, liest Git die Commit-Graph-Datei (falls vorhanden), um die Graphstruktur von Commits zu parsen. Standard ist true. Weitere Informationen finden Sie unter git-commit-graph[1].

Wenn auf false gesetzt, verhält es sich so, als ob die Option --no-replace-objects auf der Kommandozeile angegeben wurde. Weitere Informationen finden Sie unter git[1] und git-replace[1].

Verwendet die Multi-Pack-Index-Datei, um mehrere Packfiles mit einem einzigen Index zu verfolgen. Weitere Informationen finden Sie unter git-multi-pack-index[1]. Standard ist true.

Aktiviert die "Sparse Checkout"-Funktion. Weitere Informationen finden Sie unter git-sparse-checkout[1].

Aktiviert den "Cone-Modus" der Sparse Checkout-Funktion. Wenn die Sparse Checkout-Datei eine begrenzte Anzahl von Mustern enthält, bietet dieser Modus erhebliche Leistungsvorteile. Der "Non-Cone-Modus" kann angefordert werden, um flexiblere Muster zu ermöglichen, indem diese Variable auf false gesetzt wird. Weitere Informationen finden Sie unter git-sparse-checkout[1].

Legt die Länge fest, auf die Objektnamen abgekürzt werden. Wenn nicht angegeben oder auf "auto" gesetzt, wird ein geeigneter Wert basierend auf der ungefähren Anzahl der gepackten Objekte in Ihrem Repository berechnet, was hoffentlich ausreicht, damit abgekürzte Objektnamen für eine gewisse Zeit eindeutig bleiben. Wenn auf "no" gesetzt, erfolgt keine Abkürzung und die Objektnamen werden in voller Länge angezeigt. Die Mindestlänge ist 4.

Die maximale Tiefe, die Git beim Durchlaufen eines Baumes rekursiv vorgeht (z. B. "a/b/cde/f" hat eine Tiefe von 4). Dies ist eine Notfallmaßnahme, damit Git sauber abbrechen kann, und muss im Allgemeinen nicht angepasst werden. Wenn Git mit MSVC kompiliert wird, beträgt der Standardwert 512. Andernfalls beträgt der Standardwert 2048.

Gibt einen externen Helfer an, der aufgerufen wird, wenn ein Benutzername oder ein Passwort benötigt wird; der Helfer kann externe Speicher konsultieren, um die Eingabe von Anmeldeinformationen durch den Benutzer zu vermeiden. Dies ist normalerweise der Name eines Anmeldeinformationshelfers mit möglichen Argumenten, kann aber auch ein absoluter Pfad mit Argumenten sein oder, wenn er mit ! eingeleitet wird, Shell-Befehle.

Standardmäßig fragen Git und alle konfigurierten Anmeldeinformationshelfer nach Benutzereingaben, wenn neue Anmeldeinformationen benötigt werden. Viele dieser Helfer werden aufgrund gespeicherter Anmeldeinformationen erfolgreich sein, wenn diese Anmeldeinformationen noch gültig sind. Um die Möglichkeit der Benutzerinteraktivität durch Git zu vermeiden, setzen Sie credential.interactive=false. Einige Anmeldeinformationshelfer berücksichtigen diese Option ebenfalls.

Bei der Abfrage von Anmeldeinformationen wird die "Pfad"-Komponente einer http- oder https-URL als wichtig betrachtet. Standard ist false. Weitere Informationen finden Sie unter gitcredentials[7].

Standardmäßig dürfen Benutzernamen und Hosts, die als Teil der Passwortabfrage angezeigt werden, keine Steuerzeichen enthalten (sie werden standardmäßig URL-kodiert). Konfigurieren Sie diese Einstellung auf false, um dieses Verhalten zu überschreiben.

Standardmäßig sind Wagenrücklaufzeichen im Protokoll nicht erlaubt, das verwendet wird, wenn Git mit einem Anmeldeinformationshelfer kommuniziert. Diese Einstellung ermöglicht es Benutzern, diesen Standard zu überschreiben.

Wenn für eine Netzwerauthentifizierung kein Benutzername festgelegt ist, wird dieser Benutzername standardmäßig verwendet. Siehe credential.<context>.* unten und gitcredentials[7].

Jede der credential.* Optionen oben kann selektiv auf einige Anmeldeinformationen angewendet werden. Zum Beispiel würde "credential.https://example.com.username" den Standardbenutzernamen nur für https-Verbindungen zu example.com festlegen. Siehe gitcredentials[7] für Details, wie URLs abgeglichen werden.

Weist den Daemon von git-credential-cache an, SIGHUP zu ignorieren, anstatt zu beenden.

Die Zeitdauer in Millisekunden, die git-credential-store bei dem Versuch, die Anmeldeinformationsdatei zu sperren, wiederholt. Ein Wert von 0 bedeutet kein Wiederholungsversuch; -1 bedeutet unbegrenzte Versuche. Standard ist 1000 (d. h. Wiederholung für 1 Sekunde).

Wenn git diff verwendet wird, um Vergleiche mit Arbeitsbaumdateien durchzuführen, werden reine Statusänderungen nicht als geändert betrachtet. Stattdessen wird git update-index --refresh stillschweigend ausgeführt, um die Statusinformationen für Pfade zu aktualisieren, deren Inhalte im Arbeitsbaum mit den Inhalten im Index übereinstimmen. Diese Option ist standardmäßig true. Beachten Sie, dass dies nur git diff Porcelain betrifft und nicht Low-Level-diff-Befehle wie git diff-files.

Eine kommagetrennte Liste von --dirstat-Parametern, die das Standardverhalten der Option --dirstat für git-diff[1] und ähnliche Befehle angibt. Die Standardwerte können auf der Kommandozeile überschrieben werden (mit --dirstat=<param>,...). Die Fallback-Standardwerte (wenn nicht durch diff.dirstat geändert) sind changes,noncumulative,3. Die folgenden Parameter sind verfügbar

Begrenzt die Breite des Dateinamens im --stat-Output. Wenn gesetzt, gilt dies für alle Befehle, die --stat-Output generieren, außer format-patch.

Begrenzt die Breite des Graphenteils im --stat-Output. Wenn gesetzt, gilt dies für alle Befehle, die --stat-Output generieren, außer format-patch.

Generiert Diffs mit <n> Zeilen Kontext anstelle des Standardwerts von 3. Dieser Wert wird durch die Option -U überschrieben.

Zeigt den Kontext zwischen Diff-Hunks bis zur angegebenen Anzahl von Zeilen an und verschmilzt dadurch nahe beieinander liegende Hunks. Dieser Wert dient als Standard für die Kommandozeilenoption --inter-hunk-context.

Wenn diese Konfigurationsvariable gesetzt ist, wird die Diff-Generierung nicht mit der internen Diff-Maschine durchgeführt, sondern mit dem angegebenen Befehl. Kann mit der Umgebungsvariable GIT_EXTERNAL_DIFF überschrieben werden. Der Befehl wird mit Parametern aufgerufen, wie unter "git Diffs" in git[1] beschrieben. Hinweis: Wenn Sie ein externes Diff-Programm nur für eine Teilmenge Ihrer Dateien verwenden möchten, sollten Sie stattdessen gitattributes[5] verwenden.

Wenn dieser boolesche Wert auf true gesetzt ist, wird erwartet, dass der Befehl diff.external den Exit-Code 0 zurückgibt, wenn er die Eingabedateien als gleich betrachtet, oder 1, wenn er sie als unterschiedlich betrachtet, wie diff(1). Wenn er auf false gesetzt ist, was der Standard ist, wird erwartet, dass der Befehl unabhängig von der Gleichheit den Exit-Code 0 zurückgibt. Jeder andere Exit-Code führt dazu, dass Git einen fatalen Fehler meldet.

Legt den Standardwert für --ignore-submodules fest. Beachten Sie, dass dies nur git diff Porcelain betrifft und nicht Low-Level-diff-Befehle wie git diff-files. git checkout und git switch berücksichtigen diese Einstellung ebenfalls, wenn sie nicht committete Änderungen melden. Wenn sie auf all gesetzt ist, wird die Submodulübersicht, die normalerweise von git commit und git status angezeigt wird, wenn status.submoduleSummary gesetzt ist, deaktiviert, es sei denn, sie wird durch die Verwendung der Kommandozeilenoption --ignore-submodules überschrieben. Die git submodule-Befehle sind von dieser Einstellung nicht betroffen. Standardmäßig ist dies auf untracked gesetzt, sodass alle nicht nachverfolgten Submodule ignoriert werden.

Wenn gesetzt, verwendet git diff ein Präfixpaar, das sich vom Standard a/ und b/ unterscheidet, abhängig davon, was verglichen wird. Wenn diese Konfiguration aktiv ist, tauscht die Ausgabe von Reverse-Diffs auch die Reihenfolge der Präfixe.

Wenn gesetzt, zeigt git diff kein Quell- oder Zielpräfix an.

Wenn gesetzt, verwendet git diff dieses Quellpräfix. Standard ist a/.

Wenn gesetzt, verwendet git diff dieses Zielpräfix. Standard ist b/.

Wenn auf true gesetzt, zeigt git diff keine Änderungen außerhalb des Verzeichnisses an und zeigt Pfadnamen relativ zum aktuellen Verzeichnis an.

Datei, die angibt, wie Dateien innerhalb eines Diffs geordnet werden sollen. Siehe die Option -O für git-diff[1] für Details. Wenn diff.orderFile ein relativer Pfadname ist, wird er relativ zum Stamm des Arbeitsverzeichnisses behandelt.

Die Anzahl der Dateien, die im exklusiven Teil der Kopier-/Umbenennungserkennung berücksichtigt werden; entspricht der Option git diff -l. Wenn nicht gesetzt, beträgt der Standardwert derzeit 1000. Diese Einstellung hat keine Auswirkung, wenn die Umbenennungserkennung deaktiviert ist.

Ob und wie Git Umbenennungen erkennt. Wenn auf false gesetzt, ist die Umbenennungserkennung deaktiviert. Wenn auf true gesetzt, ist die grundlegende Umbenennungserkennung aktiviert. Wenn auf copies oder copy gesetzt, erkennt Git auch Kopien. Standard ist true. Beachten Sie, dass dies nur git diff Porcelain wie git-diff[1] und git-log[1] betrifft und nicht Low-Level-Befehle wie git-diff-files[1].

Ein boolescher Wert, der das Standardverhalten unterdrückt, eine Leerstelle vor jeder leeren Ausgabespur zu drucken. Standard ist false.

Gibt das Format an, in dem Unterschiede bei Submodulen angezeigt werden. Das short-Format zeigt nur die Namen der Commits am Anfang und Ende des Bereichs an. Das log-Format listet die Commits im Bereich auf, wie git-submodule summary. Das diff-Format zeigt einen Inline-Diff der geänderten Inhalte des Submoduls. Standard ist short.

Ein POSIX Extended Regular Expression, das verwendet wird, um zu bestimmen, was ein "Wort" ist, wenn Wort-für-Wort-Differenzberechnungen durchgeführt werden. Zeichensequenzen, die dem regulären Ausdruck entsprechen, sind "Wörter", alle anderen Zeichen sind zu ignorierende Leerzeichen.

Der benutzerdefinierte Diff-Treiberbefehl. Siehe gitattributes[5] für Details.

Wenn dieser boolesche Wert auf true gesetzt ist, wird erwartet, dass der Befehl diff.<driver>.command den Exit-Code 0 zurückgibt, wenn er die Eingabedateien als gleich betrachtet, oder 1, wenn er sie als unterschiedlich betrachtet, wie diff(1). Wenn er auf false gesetzt ist, was der Standard ist, wird erwartet, dass der Befehl unabhängig von der Gleichheit den Exit-Code 0 zurückgibt. Jeder andere Exit-Code führt dazu, dass Git einen fatalen Fehler meldet.

Der reguläre Ausdruck, den der Diff-Treiber verwenden sollte, um den Hunk-Header zu erkennen. Ein integriertes Muster kann ebenfalls verwendet werden. Siehe gitattributes[5] für Details.

Setzen Sie diese Option auf true, damit der Diff-Treiber Dateien als binär behandelt. Siehe gitattributes[5] für Details.

Der Befehl, den der Diff-Treiber aufrufen sollte, um die textkonvertierte Version einer Datei zu generieren. Das Ergebnis der Konvertierung wird verwendet, um einen lesbaren Diff zu generieren. Siehe gitattributes[5] für Details.

Der reguläre Ausdruck, den der Diff-Treiber verwenden sollte, um Wörter in einer Zeile zu trennen. Siehe gitattributes[5] für Details.

Setzen Sie diese Option auf true, damit der Diff-Treiber die Textkonvertierungsergebnisse cacht. Siehe gitattributes[5] für Details.

Setzen Sie diese Option auf false, um die Standardheuristiken zu deaktivieren, die Diff-Hunk-Grenzen verschieben, um Patches besser lesbar zu machen.

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

Hebt Leerzeichenfehler in den Zeilen context, old oder new des Diffs hervor. Mehrere Werte werden durch Kommas getrennt, none setzt vorherige Werte zurück, default setzt die Liste auf new zurück und all ist eine Kurzform für old,new,context. Die Leerzeichenfehler werden mit color.diff.whitespace eingefärbt. Die Kommandozeilenoption --ws-error-highlight=<kind> überschreibt diese Einstellung.

Wenn auf einen gültigen <mode> oder einen true-Wert gesetzt, werden verschobene Zeilen in einem Diff unterschiedlich eingefärbt. Details zu gültigen Modi finden Sie unter --color-moved in git-diff[1]. Wenn einfach auf true gesetzt, wird der Standard-Farbmodus verwendet. Wenn auf false gesetzt, werden verschobene Zeilen nicht eingefärbt.

Wenn verschobene Zeilen eingefärbt werden (z. B. mit der Einstellung diff.colorMoved), steuert diese Option den Modus, wie Leerzeichen behandelt werden. Details zu gültigen Modi finden Sie unter --color-moved-ws in git-diff[1].

Steuert, welcher Diff-Tool von git-difftool[1] verwendet wird. Diese Variable überschreibt den in merge.tool konfigurierten Wert. Die folgende Liste zeigt die gültigen integrierten Werte. Jeder andere Wert wird als benutzerdefiniertes Diff-Tool behandelt und erfordert, dass eine entsprechende difftool.<tool>.cmd-Variable definiert ist.

Steuert, welches Diff-Tool von git-difftool[1] verwendet wird, wenn die Option -g/--gui angegeben wird. Diese Variable überschreibt den in merge.guitool konfigurierten Wert. Die folgende Liste zeigt die gültigen integrierten Werte. Jeder andere Wert wird als benutzerdefiniertes Diff-Tool behandelt und erfordert, dass eine entsprechende difftool.<guitool>.cmd-Variable definiert ist.

Gibt den Befehl zur Ausführung des angegebenen Diff-Tools an. Der angegebene Befehl wird in der Shell mit den folgenden verfügbaren Variablen ausgewertet: LOCAL wird auf den Namen der temporären Datei gesetzt, die den Inhalt des Diff-Pre-Images enthält, und REMOTE wird auf den Namen der temporären Datei gesetzt, die den Inhalt des Diff-Post-Images enthält.

Überschreibt den Pfad für das gegebene Tool. Dies ist nützlich, falls Ihr Tool nicht im PATH enthalten ist.

Beendet difftool, wenn das aufgerufene Diff-Tool einen von Null verschiedenen Exit-Status zurückgibt.

Fordert zur Bestätigung vor jeder Ausführung des Diff-Tools auf.

Setzen Sie auf true, um diff.guitool standardmäßig zu verwenden (entspricht der Angabe des Arguments --gui), oder auto, um diff.guitool oder diff.tool auszuwählen, je nachdem, ob eine DISPLAY-Umgebungsvariable vorhanden ist. Der Standard ist false, wobei das Argument --gui explizit angegeben werden muss, damit diff.guitool verwendet wird.

Sofern nicht anders angegeben, ist es ein Fehler, eine Erweiterung anzugeben, wenn core.repositoryFormatVersion nicht 1 ist. Siehe gitrepository-layout[5].

Wenn die Anzahl der von git-fast-import[1] importierten Objekte unter diesem Limit liegt, werden die Objekte in lose Objektdateien entpackt. Wenn jedoch die Anzahl der importierten Objekte dieses Limit erreicht oder überschreitet, wird das Pack als Pack gespeichert. Das Speichern des Packs aus einem Fast-Import kann den Importvorgang beschleunigen, insbesondere auf langsamen Dateisystemen. Wenn nicht gesetzt, wird stattdessen der Wert von transfer.unpackLimit verwendet.

Die Konfigurationseinstellungen, die mit feature. beginnen, modifizieren die Standardwerte einer Gruppe anderer Konfigurationseinstellungen. Diese Gruppen werden von der Git-Entwickler-Community als empfohlene Standardwerte erstellt und können sich ändern. Insbesondere können neue Konfigurationsoptionen mit anderen Standardwerten hinzugefügt werden.

Aktiviert Konfigurationsoptionen, die neu in Git sind und für zukünftige Standardwerte in Betracht gezogen werden. Hierin enthaltene Konfigurationseinstellungen können mit jeder Veröffentlichung, einschließlich kleiner Versionsupdates, hinzugefügt oder entfernt werden. Diese Einstellungen können aufgrund ihrer Neuheit unbeabsichtigte Wechselwirkungen haben. Bitte aktivieren Sie diese Einstellung, wenn Sie interessiert sind, Feedback zu experimentellen Funktionen zu geben. Die neuen Standardwerte sind

Aktiviert Konfigurationsoptionen, die für Repositories mit vielen Dateien im Arbeitsverzeichnis optimiert sind. Bei vielen Dateien können Befehle wie git status und git checkout langsam sein, und diese neuen Standardwerte verbessern die Leistung.

Diese Option steuert, ob git fetch (und der zugrunde liegende Fetch in git pull) rekursiv in befüllte Submodule holt. Diese Option kann entweder auf einen booleschen Wert oder auf on-demand gesetzt werden. Wenn sie auf einen booleschen Wert gesetzt wird, ändert sich das Verhalten von fetch und pull, so dass sie bedingungslos in Submodule rekursieren, wenn sie auf true gesetzt ist, oder gar nicht rekursieren, wenn sie auf false gesetzt ist. Wenn sie auf on-demand gesetzt ist, rekursieren fetch und pull nur in ein befülltes Submodul, wenn sein Superprojekt einen Commit abruft, der die Referenz des Submoduls aktualisiert. Standardmäßig ist sie on-demand oder auf den Wert von submodule.recurse gesetzt, falls dieser gesetzt ist.

Wenn auf true gesetzt, prüft git-fetch-pack alle geholten Objekte. Lesen Sie transfer.fsckObjects, um zu sehen, was geprüft wird. Standardmäßig false. Wenn nicht gesetzt, wird der Wert von transfer.fsckObjects stattdessen verwendet.

Verhält sich wie fsck.<msg-id>, wird aber von git-fetch-pack[1] anstelle von git-fsck[1] verwendet. Einzelheiten finden Sie in der Dokumentation zu fsck.<msg-id>.

Verhält sich wie fsck.skipList, wird aber von git-fetch-pack[1] anstelle von git-fsck[1] verwendet. Einzelheiten finden Sie in der Dokumentation zu fsck.skipList.

Wenn die Anzahl der über den Git-nativen Transfer geholten Objekte unter diesem Limit liegt, werden die Objekte in lose Objektdateien entpackt. Wenn die Anzahl der empfangenen Objekte dieses Limit erreicht oder überschreitet, wird das empfangene Pack als Pack gespeichert, nachdem alle fehlenden Delta-Basen hinzugefügt wurden. Das Speichern des Packs von einem Push kann den Push-Vorgang beschleunigen, insbesondere auf langsamen Dateisystemen. Wenn nicht gesetzt, wird der Wert von transfer.unpackLimit stattdessen verwendet.

Wenn true, verhält sich fetch automatisch so, als ob die Option --prune auf der Kommandozeile angegeben worden wäre. Siehe auch remote.<name>.prune und den Abschnitt PRUNING in git-fetch[1].

Wenn true, verhält sich fetch automatisch so, als ob das Refspec refs/tags/*:refs/tags/* beim Löschen angegeben wurde, falls es noch nicht gesetzt ist. Dies ermöglicht die Einstellung sowohl dieser Option als auch von fetch.prune, um eine 1:1-Zuordnung zu den Upstream-Refs beizubehalten. Siehe auch remote.<name>.pruneTags und den Abschnitt PRUNING in git-fetch[1].

Wenn true, versucht fetch, alle verfügbaren Remote-Repositories zu aktualisieren. Dieses Verhalten kann durch Angabe von --no-all oder durch explizite Angabe eines oder mehrerer Remote-Repositories, von denen geholt werden soll, überschrieben werden. Standardmäßig false.

Steuert, wie der Status von Ref-Updates ausgegeben wird. Gültige Werte sind full und compact. Der Standardwert ist full. Einzelheiten finden Sie im Abschnitt OUTPUT in git-fetch[1].

Steuert, wie Informationen über die Commits im lokalen Repository gesendet werden, wenn die Inhalte des vom Server zu sendenden Packfiles ausgehandelt werden. Setzen Sie auf "consecutive", um einen Algorithmus zu verwenden, der aufeinanderfolgende Commits durchläuft und jeden einzelnen prüft. Setzen Sie auf "skipping", um einen Algorithmus zu verwenden, der Commits überspringt, um schneller zu konvergieren, aber zu einem unnötig großen Packfile führen kann; oder setzen Sie auf "noop", um überhaupt keine Informationen zu senden, was mit ziemlicher Sicherheit zu einem unnötig großen Packfile führt, aber den Verhandlungsschritt überspringt. Setzen Sie auf "default", um zuvor getroffene Einstellungen zu überschreiben und das Standardverhalten zu verwenden. Standardmäßig ist dies normalerweise "consecutive", aber wenn feature.experimental true ist, ist der Standardwert "skipping". Unbekannte Werte führen dazu, dass git fetch einen Fehler ausgibt.

Auf false setzen, um --no-show-forced-updates in den Befehlen git-fetch[1] und git-pull[1] zu aktivieren. Standardmäßig true.

Gibt die maximale Anzahl von Fetch-Operationen an, die gleichzeitig parallel ausgeführt werden sollen (Submodule oder Remotes, wenn die Option --multiple von git-fetch[1] aktiv ist).

Auf true setzen, um nach jedem git fetch-Befehl, der ein Packfile von einem Remote-Repository herunterlädt, einen Commit-Graphen zu schreiben. Mit der Option --split erstellen die meisten Ausführungen eine sehr kleine Commit-Graph-Datei zusätzlich zu den vorhandenen Commit-Graph-Dateien. Gelegentlich werden diese Dateien zusammengeführt, und das Schreiben kann länger dauern. Ein aktualisierter Commit-Graph verbessert die Leistung vieler Git-Befehle, einschließlich git merge-base, git push -f und git log --graph. Standardmäßig false.

Dieser Wert speichert eine URI zum Herunterladen von Git-Objektdaten aus einer Bundle-URI, bevor ein inkrementeller Fetch vom ursprünglichen Git-Server durchgeführt wird. Dies ähnelt dem Verhalten der Option --bundle-uri in git-clone[1]. git clone --bundle-uri setzt den Wert von fetch.bundleURI, wenn die angegebene Bundle-URI eine Bundle-Liste enthält, die für inkrementelle Fetches organisiert ist.

Wenn fetch.bundleURI zum inkrementellen Abrufen aus einer Bundle-Liste verwendet wird, die die "creationToken"-Heuristik verwendet, speichert dieser Konfigurationswert den maximalen creationToken-Wert der heruntergeladenen Bundles. Dieser Wert wird verwendet, um das Herunterladen von Bundles in Zukunft zu verhindern, wenn der angegebene creationToken nicht strikt größer als dieser Wert ist.

Der Befehl, der verwendet wird, um den Inhalt einer Arbeitsbaumdatei beim Einchecken in einen Blob zu konvertieren. Einzelheiten finden Sie unter gitattributes[5].

Der Befehl, der verwendet wird, um den Inhalt eines Blob-Objekts beim Auschecken in eine Arbeitsbaumdatei zu konvertieren. Einzelheiten finden Sie unter gitattributes[5].

Aktiviert multipart/mixed-Anhänge als Standard für format-patch. Der Wert kann auch eine Zeichenkette in doppelten Anführungszeichen sein, die Anhänge als Standard aktiviert und den Wert als Trennzeichen festlegt. Siehe die Option --attach in git-format-patch[1]. Um einen früheren Wert zu widerrufen, setzen Sie ihn auf eine leere Zeichenkette.

Bietet den Standardwert für die Option --from für format-patch. Akzeptiert einen booleschen Wert oder einen Namen und eine E-Mail-Adresse. Wenn false, verwendet format-patch standardmäßig --no-from und verwendet die Commit-Autoren direkt im "From:"-Feld von Patch-Mails. Wenn true, verwendet format-patch standardmäßig --from und verwendet Ihre Committer-Identität im "From:"-Feld von Patch-Mails und fügt ein "From:"-Feld im Body der Patch-Mail hinzu, wenn es abweicht. Wenn auf einen nicht-booleschen Wert gesetzt, verwendet format-patch diesen Wert anstelle Ihrer Committer-Identität. Standardmäßig false.

Bietet den Standardwert für die Option --[no-]force-in-body-from für format-patch. Standardmäßig false.

Ein boolescher Wert, der Sequenznummern in Patch-Betreffzeilen aktivieren oder deaktivieren kann. Standardmäßig "auto", was sie nur aktiviert, wenn mehr als ein Patch vorhanden ist. Sie kann für alle Nachrichten aktiviert oder deaktiviert werden, indem sie auf "true" oder "false" gesetzt wird. Siehe die Option --numbered in git-format-patch[1].

Zusätzliche E-Mail-Header, die in einen Patch aufgenommen werden sollen, der per E-Mail übermittelt wird. Siehe git-format-patch[1].

Zusätzliche Empfänger, die in einen Patch aufgenommen werden sollen, der per E-Mail übermittelt wird. Siehe die Optionen --to und --cc in git-format-patch[1].

Der Standard für format-patch ist die Ausgabe von Dateien mit dem Betreff-Präfix [PATCH]. Verwenden Sie diese Variable, um dieses Präfix zu ändern.

Der Standardmodus für format-patch, um zu bestimmen, welche Teile des Anschreibens mit der Beschreibung des Branches gefüllt werden. Siehe die Option --cover-from-description in git-format-patch[1].

Der Standard für format-patch ist die Ausgabe einer Signatur mit der Git-Versionsnummer. Verwenden Sie diese Variable, um diesen Standard zu ändern. Setzen Sie diese Variable auf eine leere Zeichenkette (""), um die Signaturerstellung zu unterdrücken.

Funktioniert genauso wie format.signature, nur dass der Inhalt der durch diese Variable angegebenen Datei als Signatur verwendet wird.

Der Standard für format-patch ist die Ausgabe von Dateien mit der Endung .patch. Verwenden Sie diese Variable, um diese Endung zu ändern (stellen Sie sicher, dass Sie den Punkt einschließen, wenn Sie ihn möchten).

Kodiert E-Mail-Header mit Nicht-ASCII-Zeichen mit "Q-Encoding" (beschrieben in RFC 2047) für die E-Mail-Übertragung. Standardmäßig true.

Das Standardformat für die Ausgabe von log/show/whatchanged-Befehlen. Siehe git-log[1], git-show[1], git-whatchanged[1].

Der Standard-Threading-Stil für git format-patch. Kann ein boolescher Wert sein oder shallow oder deep. 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-E-Mail in dieser Reihenfolge gewählt wird. deep-Threading macht jede E-Mail zu einer Antwort auf die vorherige. Ein wahrer boolescher Wert ist dasselbe wie shallow, und ein falscher Wert deaktiviert das Threading.

Ein boolescher Wert, mit dem die Option -s/--signoff von format-patch standardmäßig aktiviert werden kann. Hinweis: Das Hinzufügen des Signed-off-by-Trailers zu einem Patch sollte eine bewusste Handlung sein und bedeutet, dass Sie zertifizieren, dass Sie das Recht haben, diese Arbeit unter derselben Open-Source-Lizenz einzureichen. Weitere Informationen finden Sie im Dokument SubmittingPatches.

Ein boolescher Wert, der steuert, ob ein Anschreiben generiert wird, wenn format-patch aufgerufen wird, kann aber auch auf "auto" gesetzt werden, um nur dann ein Anschreiben zu generieren, wenn mehr als ein Patch vorhanden ist. Standardmäßig false.

Legen Sie ein benutzerdefiniertes Verzeichnis fest, in dem die resultierenden Dateien gespeichert werden sollen, anstatt im aktuellen Arbeitsverzeichnis. Alle Verzeichniskomponenten werden erstellt.

Die maximale Länge der von format-patch generierten Ausgabedateinamen; standardmäßig 64. Kann durch die Kommandozeilenoption --filename-max-length=<n> überschrieben werden.

Ein boolescher Wert, mit dem die Option --base=auto von format-patch standardmäßig aktiviert werden kann. Kann auch auf "whenAble" gesetzt werden, um die Aktivierung von --base=auto zu ermöglichen, wenn eine geeignete Basis verfügbar ist, aber andernfalls das Hinzufügen von Basisinformationen zu überspringen, ohne dass format abbricht.

Bietet den Standardwert für die Option --notes für format-patch. Akzeptiert einen booleschen Wert oder einen Ref, der angibt, wo Notizen bezogen werden sollen. Wenn false, verwendet format-patch standardmäßig --no-notes. Wenn true, verwendet format-patch standardmäßig --notes. Wenn auf einen nicht-booleschen Wert gesetzt, verwendet format-patch standardmäßig --notes=<ref>, wobei ref der nicht-boolesche Wert ist. Standardmäßig false.

[format]
	notes = true
	notes = foo
	notes = false
	notes = bar

Ein boolescher Wert, der das robuste "mboxrd"-Format aktiviert, wenn --stdout verwendet wird, um Zeilen, die mit ">From " beginnen, zu escapen.

Wenn gesetzt, werden keine Quell- oder Zielpräfixe in Patches angezeigt. Dies ist äquivalent zur Option diff.noprefix, die von git diff verwendet wird (aber von format-patch nicht berücksichtigt wird). Beachten Sie, dass Empfänger von Patches, die Sie generieren, diese mit der Option -p0 anwenden müssen, wenn Sie diese Option setzen.

Während fsck kann Git Probleme mit Legacy-Daten finden, die nicht von aktuellen Git-Versionen generiert würden und die nicht über das Netzwerk gesendet würden, wenn transfer.fsckObjects gesetzt wäre. Dieses Feature ist dazu gedacht, mit Legacy-Repositories zu arbeiten, die solche Daten enthalten.

Der Pfad zu einer Liste von Objektnamen (d. h. eine unabgekürzte SHA-1 pro Zeile), von denen bekannt ist, dass sie auf nicht-fatale Weise fehlerhaft sind und ignoriert werden sollten. Auf Git-Versionen 2.20 und neuer werden Kommentare (#), leere Zeilen und beliebige führende und nachgestellte Leerzeichen ignoriert. Alles außer einer SHA-1 pro Zeile führt auf älteren Versionen zu einem Fehler.

Standardmäßig weigert sich der fsmonitor-Daemon, mit netzwerkgebundenen Repositories zu arbeiten. Das Setzen von fsmonitor.allowRemote auf true überschreibt dieses Verhalten. Nur beachtet, wenn core.fsmonitor auf true gesetzt ist.

Diese Mac OS-spezifische Option, wenn sie gesetzt ist, gibt das Verzeichnis an, in dem der Unix-Domain-Socket erstellt werden soll, der für die Kommunikation zwischen dem fsmonitor-Daemon und verschiedenen Git-Befehlen verwendet wird. Das Verzeichnis muss sich auf einem nativen Mac OS-Dateisystem befinden. Nur beachtet, wenn core.fsmonitor auf true gesetzt ist.

Der Tiefenparameter, der im Delta-Komprimierungsalgorithmus von git gc --aggressive verwendet wird. Dieser hat einen Standardwert von 50, was dem Standardwert für die Option --depth entspricht, wenn --aggressive nicht verwendet wird.

Der Fenstergrößenparameter, der im Delta-Komprimierungsalgorithmus von git gc --aggressive verwendet wird. Dieser hat einen Standardwert von 250, was eine wesentlich aggressivere Fenstergröße ist als der Standardwert --window von 10.

Wenn ungefähr mehr als diese Anzahl loser Objekte im Repository vorhanden ist, packt git gc --auto diese. Einige Porcelain-Befehle verwenden diesen Befehl, um von Zeit zu Zeit eine leichtgewichtige Garbage Collection durchzuführen. Der Standardwert ist 6700.

Wenn mehr als diese Anzahl von Packs, die nicht mit einer *.keep-Datei im Repository gekennzeichnet sind, vorhanden ist, konsolidiert git gc --auto diese zu einem größeren Pack. Der Standardwert ist 50. Das Setzen auf 0 deaktiviert dies. Das Setzen von gc.auto auf 0 deaktiviert dies ebenfalls.

Lassen Sie git gc --auto sofort zurückkehren und im Hintergrund laufen, wenn das System dies unterstützt. Standard ist true. Diese Konfigurationsvariable dient als Fallback, falls maintenance.autoDetach nicht gesetzt ist.

Wenn ungleich null, werden alle Nicht-Cruft-Packs, die größer als dieser Grenzwert sind, bei Ausführung von git gc beibehalten. Dies ist sehr ähnlich zu --keep-largest-pack, außer dass alle Nicht-Cruft-Packs, die den Schwellenwert erfüllen, beibehalten werden, nicht nur das größte Pack. Standard ist null. Übliche Einheiten-Suffixe von k, m oder g werden unterstützt.

Wenn true, dann schreibt gc den Commit-Graph neu, wenn git-gc[1] ausgeführt wird. Bei Verwendung von git gc --auto wird der Commit-Graph aktualisiert, wenn eine Wartung erforderlich ist. Standard ist true. Einzelheiten finden Sie unter git-commit-graph[1].

Wenn die Datei gc.log existiert, gibt git gc --auto ihren Inhalt aus und wird mit dem Status null beendet, anstatt ausgeführt zu werden, es sei denn, diese Datei ist älter als gc.logExpiry. Standard ist "1.day". Weitere Möglichkeiten zur Angabe ihres Werts finden Sie unter gc.pruneExpire.

Das Ausführen von git pack-refs in einem Repository macht es für Git-Versionen vor 1.5.1.2 über langsame Transporte wie HTTP unklonbar. Diese Variable bestimmt, ob git gc git pack-refs ausführt. Dies kann auf notbare gesetzt werden, um es in allen nicht-bare Repos zu aktivieren, oder es kann auf einen booleschen Wert gesetzt werden. Der Standardwert ist true.

Speichert nicht erreichbare Objekte in einem Cruft-Pack (siehe git-repack[1]) anstelle von losen Objekten. Der Standardwert ist true.

Begrenzt die Größe neuer Cruft-Packs beim Repacking. Wenn dies zusätzlich zu --max-cruft-size angegeben wird, hat die Kommandozeilenoption Vorrang. Siehe die Option --max-cruft-size von git-repack[1].

Wenn git gc ausgeführt wird, ruft es prune --expire 2.weeks.ago auf (und repack --cruft --cruft-expiration 2.weeks.ago, wenn Cruft-Packs über gc.cruftPacks oder --cruft verwendet werden). Überschreiben Sie die Kulanzzeit mit dieser Konfigurationsvariable. Der Wert "now" kann verwendet werden, um diese Kulanzzeit zu deaktivieren und nicht erreichbare Objekte sofort zu löschen, oder "never" kann verwendet werden, um das Löschen zu unterdrücken. Diese Funktion hilft, Beschädigungen zu verhindern, wenn git gc gleichzeitig mit einem anderen Prozess ausgeführt wird, der in das Repository schreibt; siehe den Abschnitt "NOTES" von git-gc[1].

Wenn git gc ausgeführt wird, ruft es git worktree prune --expire 3.months.ago auf. Diese Konfigurationsvariable kann verwendet werden, um eine andere Kulanzzeit festzulegen. Der Wert "now" kann verwendet werden, um die Kulanzzeit zu deaktivieren und $GIT_DIR/worktrees sofort zu bereinigen, oder "never" kann verwendet werden, um die Bereinigung zu unterdrücken.

git reflog expire entfernt Reflog-Einträge, die älter als diese Zeit sind; Standard ist 90 Tage. Der Wert "now" löscht alle Einträge sofort und "never" unterdrückt das Löschen vollständig. Mit "<pattern>" (z. B. "refs/stash") in der Mitte gilt die Einstellung nur für die mit dem Muster übereinstimmenden Refs.

git reflog expire entfernt Reflog-Einträge, die älter als diese Zeit sind und nicht vom aktuellen Tipppunkt aus erreichbar sind; Standard ist 30 Tage. Der Wert "now" löscht alle Einträge sofort und "never" unterdrückt das Löschen vollständig. Mit "<pattern>" (z. B. "refs/stash") in der Mitte gilt die Einstellung nur für die mit dem Muster übereinstimmenden Refs.

Bei der Entscheidung, ob ein Objekt entfernt werden soll (entweder beim Generieren eines Cruft-Packs oder beim Speichern nicht erreichbarer Objekte als lose Objekte), wird die Shell verwendet, um die angegebenen Befehle auszuführen. Interpretiert deren Ausgabe als Objekt-IDs, die Git als "aktuell" betrachtet, unabhängig von ihrem Alter. Indem ihre mtimes als "jetzt" behandelt werden, werden alle Objekte (und ihre Nachfolger), die in der Ausgabe erwähnt werden, unabhängig von ihrem tatsächlichen Alter beibehalten.

Beim Repacking wird der angegebene Filter verwendet, um bestimmte Objekte in eine separate Packdatei zu verschieben. Siehe die Option --filter=<filter-spec> von git-repack[1].

Beim Repacking und der Verwendung eines Filters, siehe gc.repackFilter, wird der angegebene Speicherort verwendet, um die Packdatei mit den gefilterten Objekten zu erstellen. **WARNUNG:** Der angegebene Speicherort sollte zugänglich sein, z. B. über den Git-Alternates-Mechanismus, da das Repository sonst von Git als beschädigt betrachtet werden könnte, da es möglicherweise nicht auf die Objekte in dieser Packdatei zugreifen kann. Siehe die Option --filter-to=<dir> von git-repack[1] und den Abschnitt objects/info/alternates von gitrepository-layout[5].

Aufzeichnungen von zuvor aufgelösten Merge-Konflikten werden für diese Anzahl von Tagen aufbewahrt, wenn git rerere gc ausgeführt wird. Sie können auch menschenlesbarere Formate wie "1.month.ago" usw. verwenden. Der Standardwert sind 60 Tage. Siehe git-rerere[1].

Aufzeichnungen von nicht aufgelösten Merge-Konflikten werden für diese Anzahl von Tagen aufbewahrt, wenn git rerere gc ausgeführt wird. Sie können auch menschenlesbarere Formate wie "1.month.ago" usw. verwenden. Der Standardwert sind 15 Tage. Siehe git-rerere[1].

Hängt diese Zeichenkette an jede Commit-Nachricht an. Auf eine leere Zeichenkette setzen, um diese Funktion zu deaktivieren. Standardmäßig "via git-CVS emulator".

Ob die CVS-Server-Schnittstelle für dieses Repository aktiviert ist. Siehe git-cvsserver[1].

Pfad zu einer Protokolldatei, in die die CVS-Server-Schnittstelle verschiedene Dinge protokolliert. Siehe git-cvsserver[1].

Wenn true, sucht der Server nach den Zeilenendkonvertierungsattributen für Dateien, um die -k-Modi zu bestimmen. Wenn die Attribute Git zwingen, eine Datei als Text zu behandeln, wird der -k-Modus leer gelassen, damit CVS-Clients sie als Text behandeln. Wenn sie die Textkonvertierung unterdrücken, wird die Datei mit dem Modus -kb gesetzt, was jede Zeilenende-Bearbeitung unterdrückt, die der Client sonst möglicherweise durchführt. Wenn die Attribute den Dateityp nicht bestimmen können, wird gitcvs.allBinary verwendet. Siehe gitattributes[5].

Dies wird verwendet, wenn gitcvs.usecrlfattr nicht den richtigen -kb-Modus bestimmt. Wenn true, werden alle nicht aufgelösten Dateien im Modus -kb an den Client gesendet. Dies veranlasst den Client, sie als Binärdateien zu behandeln, was jede Zeilenende-Bearbeitung unterdrückt, die er sonst möglicherweise durchführt. Alternativ, wenn er auf "guess" gesetzt ist, werden die Inhalte der Datei untersucht, um zu entscheiden, ob sie binär ist, ähnlich wie bei core.autocrlf.

Datenbank, die von git-cvsserver zum Zwischenspeichern von Revisionsinformationen aus dem Git-Repository verwendet wird. Die genaue Bedeutung hängt vom verwendeten Datenbanktreiber ab; für SQLite (Standardtreiber) ist dies ein Dateiname. Unterstützt Variablensubstitution (siehe git-cvsserver[1] für Details). Darf keine Semikolons (;) enthalten. Standard: %Ggitcvs.%m.sqlite

Verwendeter Perl DBI-Treiber. Sie können hier jeden verfügbaren Treiber angeben, aber er funktioniert möglicherweise nicht. git-cvsserver wird mit DBD::SQLite getestet, soll mit DBD::Pg funktionieren und soll **nicht** mit DBD::mysql funktionieren. Experimentelle Funktion. Darf keine Doppelpunkte (:) enthalten. Standard: SQLite. Siehe git-cvsserver[1].

Datenbankbenutzer und -passwort. Nur nützlich, wenn gitcvs.dbDriver gesetzt ist, da SQLite keine Datenbankbenutzer und/oder -passwörter kennt. gitcvs.dbUser unterstützt Variablensubstitution (siehe git-cvsserver[1] für Details).

Präfix für den Namen der Datenbanktabellen. Wird den Namen aller verwendeten Datenbanktabellen vorangestellt, wodurch eine einzelne Datenbank für mehrere Repositories verwendet werden kann. Unterstützt Variablensubstitution (siehe git-cvsserver[1] für Details). Alle nicht-alphabetischen Zeichen werden durch Unterstriche ersetzt.

Siehe gitweb[1] für die Beschreibung.

Siehe gitweb.conf[5] für die Beschreibung.

Pfad zum Programm, das anstelle von "gpg" beim Erstellen oder Überprüfen einer PGP-Signatur verwendet wird. Das Programm muss die gleiche Befehlszeilenschnittstelle wie GPG unterstützen, d. h., um eine abgetrennte Signatur zu überprüfen, wird "gpg --verify $signature - <$file" ausgeführt, und das Programm muss eine gültige Signatur signalisieren, indem es mit dem Exit-Code 0 beendet wird. Um eine abgetrennte ASCII-signierte Signatur zu generieren, wird die Standardeingabe von "gpg -bsau $key" mit dem zu signierenden Inhalt gefüttert, und das Programm muss das Ergebnis an seine Standardausgabe senden.

Gibt das Schlüsselformat an, das beim Signieren mit --gpg-sign verwendet wird. Standard ist "openpgp". Andere mögliche Werte sind "x509", "ssh".

Verwenden Sie dies, um das Programm für das von Ihnen gewählte Signaturformat anzupassen (siehe gpg.program und gpg.format). gpg.program kann weiterhin als Legacy-Synonym für gpg.openpgp.program verwendet werden. Der Standardwert für gpg.x509.program ist "gpgsm" und für gpg.ssh.program ist es "ssh-keygen".

Gibt eine minimale Vertrauensstufe für die Signaturprüfung an. Wenn diese Option nicht gesetzt ist, erfordert die Signaturprüfung für Merge-Vorgänge einen Schlüssel mit mindestens "marginal" Vertrauen. Andere Operationen, die eine Signaturprüfung durchführen, erfordern einen Schlüssel mit mindestens "undefined" Vertrauen. Das Setzen dieser Option überschreibt die erforderliche Vertrauensstufe für alle Operationen. Unterstützte Werte, in zunehmender Reihenfolge der Bedeutung:

Dieser Befehl wird ausgeführt, wenn user.signingkey nicht gesetzt ist und eine SSH-Signatur angefordert wird. Bei erfolgreichem Beenden wird ein gültiger SSH-öffentlicher Schlüssel, der mit key:: beginnt, in der ersten Zeile seiner Ausgabe erwartet. Dies ermöglicht einem Skript die dynamische Suche nach dem richtigen öffentlichen Schlüssel, wenn eine statische Konfiguration von user.signingKey unpraktisch ist. Zum Beispiel, wenn Schlüssel oder SSH-Zertifikate häufig rotiert werden oder die Auswahl des richtigen Schlüssels von externen Faktoren abhängt, die Git nicht bekannt sind.

Eine Datei, die SSH-öffentliche Schlüssel enthält, denen Sie vertrauen möchten. Die Datei besteht aus einer oder mehreren Zeilen mit Prinzipalen gefolgt von einem SSH-öffentlichen Schlüssel. z. B.: user1@example.com,user2@example.com ssh-rsa AAAAX1... Details finden Sie unter ssh-keygen(1) "ALLOWED SIGNERS". Der Prinzipal wird nur zur Identifizierung des Schlüssels verwendet und ist bei der Überprüfung einer Signatur verfügbar.

Entweder eine SSH-KRL oder eine Liste von widerrufenen öffentlichen Schlüsseln (ohne das Prinzipal-Präfix). Siehe ssh-keygen(1) für Details. Wenn ein öffentlicher Schlüssel in dieser Datei gefunden wird, wird er immer mit der Vertrauensstufe "never" behandelt und Signaturen werden als ungültig angezeigt.

Wenn auf true gesetzt, wird die Option -n standardmäßig aktiviert.

Wenn auf true gesetzt, wird die Option --column standardmäßig aktiviert.

Legt das Standard-Matching-Verhalten fest. Die Verwendung eines Wertes von basic, extended, fixed oder perl aktiviert entsprechend die Option --basic-regexp, --extended-regexp, --fixed-strings oder --perl-regexp, während der Wert default die Option grep.extendedRegexp verwendet, um zwischen basic und extended zu wählen.

Wenn auf true gesetzt, wird die Option --extended-regexp standardmäßig aktiviert. Diese Option wird ignoriert, wenn die Option grep.patternType auf einen anderen Wert als default gesetzt ist.

Anzahl der zu verwendenden Grep-Worker-Threads. Wenn nicht gesetzt (oder auf 0 gesetzt), verwendet Git so viele Threads wie die Anzahl der verfügbaren logischen Kerne.

Wenn auf true gesetzt, wird die Option --full-name standardmäßig aktiviert.

Wenn auf true gesetzt, wird auf git grep --no-index zurückgegriffen, wenn git grep außerhalb eines Git-Repositorys ausgeführt wird. Standard ist false.

Definiert die Breite des Commit-Nachrichtenfensters in git-gui[1]. "75" ist der Standard.

Gibt an, wie viele Kontextzeilen bei Diff-Aufrufen von git-gui[1] verwendet werden sollen. Der Standardwert ist "5".

Bestimmt, ob git-gui[1] nicht verfolgte Dateien in der Dateiliste anzeigt. Der Standardwert ist "true".

Gibt die Standardzeichenkodierung an, die zur Anzeige von Dateiinhalten in git-gui[1] und gitk[1] verwendet werden soll. Sie kann durch Setzen des encoding-Attributs für relevante Dateien (siehe gitattributes[5]) überschrieben werden. Wenn diese Option nicht gesetzt ist, verwenden die Werkzeuge standardmäßig die Locale-Kodierung.

Bestimmt, ob neu erstellte Branches mit git-gui[1] standardmäßig Remote-Branches mit übereinstimmenden Namen verfolgen oder nicht. Standard: "false".

Wird als vorgeschlagener Name beim Erstellen neuer Branches mit git-gui[1] verwendet.

"true", wenn git-gui[1] Remote-Tracking-Branches beim Abrufen bereinigen soll. Der Standardwert ist "false".

Bestimmt, ob git-gui[1] den Änderungszeitstempel der Datei vertrauen soll oder nicht. Standardmäßig wird den Zeitstempeln nicht vertraut.

Gibt das Wörterbuch an, das für die Rechtschreibprüfung von Commit-Nachrichten in git-gui[1] verwendet wird. Wenn es auf "none" gesetzt ist, ist die Rechtschreibprüfung deaktiviert.

Wenn true, verwendet git gui blame -C anstelle von -C -C für die Erkennung des ursprünglichen Speicherorts. Dies macht Blame bei riesigen Repositories erheblich schneller, auf Kosten einer weniger gründlichen Kopiererkennung.

Gibt den Schwellenwert für die Erkennung des ursprünglichen Speicherorts in git gui blame an, gemessen in alphanumerischen Zeichen. Weitere Informationen zur Kopiererkennung finden Sie im Handbuch zu git-blame[1].

Gibt den Radius des Historienkontextes in Tagen an, der in gitk[1] für den ausgewählten Commit angezeigt wird, wenn der Menüpunkt Show History Context aus git gui blame aufgerufen wird. Wenn diese Variable auf Null gesetzt ist, wird die gesamte Historie angezeigt.

Gibt die Shell-Befehlszeile an, die ausgeführt wird, wenn das entsprechende Element des git-gui[1] Tools-Menüs aufgerufen wird. Diese Option ist für jedes Tool obligatorisch. Der Befehl wird vom Stammverzeichnis des Arbeitsverzeichnisses aus ausgeführt, und in der Umgebung werden ihm der Name des Tools als GIT_GUITOOL, der Name der aktuell ausgewählten Datei als FILENAME und der Name des aktuellen Branches als CUR_BRANCH (wenn der Head gelöst ist, ist CUR_BRANCH leer) übergeben.

Führt das Tool nur aus, wenn ein Diff in der GUI ausgewählt ist. Es garantiert, dass FILENAME nicht leer ist.

Führt den Befehl stillschweigend aus, ohne ein Fenster zu erstellen, um seine Ausgabe anzuzeigen.

Scannt das Arbeitsverzeichnis nach Änderungen nicht erneut, nachdem das Tool ausgeführt wurde.

Zeigt einen Bestätigungsdialog an, bevor das Tool tatsächlich ausgeführt wird.

Fordert einen String-Argument vom Benutzer an und übergibt ihn über die Umgebungsvariable ARGS an das Tool. Da die Anforderung eines Arguments eine Bestätigung impliziert, hat die Option confirm keine Wirkung, wenn diese aktiviert ist. Wenn die Option auf true, yes oder 1 gesetzt ist, verwendet der Dialog eine integrierte generische Aufforderung; andernfalls wird der exakte Wert der Variablen verwendet.

Fordert eine einzelne gültige Revision vom Benutzer an und setzt die Umgebungsvariable REVISION. In anderen Aspekten ist diese Option ähnlich wie argPrompt und kann zusammen mit ihr verwendet werden.

Zeigt nur nicht zusammengeführte Branches im revPrompt-Unterdialog an. Dies ist nützlich für Tools, die ähnlich wie merge oder rebase funktionieren, aber nicht für Dinge wie checkout oder reset.

Gibt den Titel an, der für den Aufforderungsdialog verwendet werden soll. Standard ist der Toolname.

Gibt die allgemeine Aufforderungszeichenkette an, die oben im Dialog angezeigt wird, vor den Unterabschnitten für argPrompt und revPrompt. Der Standardwert enthält den eigentlichen Befehl.

Gibt den Browser an, der zur Anzeige von Hilfe im web-Format verwendet wird. Siehe git-help[1].

Überschreibt das Standard-Hilfeformat, das von git-help[1] verwendet wird. Die Werte man, info, web und html werden unterstützt. man ist der Standard. web und html sind identisch.

Wenn Git Tippfehler erkennt und genau einen gültigen Befehl identifizieren kann, der dem Fehler ähnelt, versucht Git, den korrekten Befehl vorzuschlagen oder die vorgeschlagene Korrektur sogar automatisch auszuführen. Mögliche Konfigurationswerte sind:

Gibt den Pfad an, an dem die HTML-Dokumentation gespeichert ist. Dateisystempfade und URLs werden unterstützt. HTML-Seiten werden mit diesem Pfad präfixiert, wenn Hilfe im web-Format angezeigt wird. Dies ist standardmäßig der Dokumentationspfad Ihrer Git-Installation.

Überschreibt den HTTP-Proxy, der normalerweise über die Umgebungsvariablen http_proxy, https_proxy und all_proxy konfiguriert wird (siehe curl(1)). Zusätzlich zur von curl verstandenen Syntax ist es möglich, eine Proxy-Zeichenkette mit einem Benutzernamen, aber ohne Passwort anzugeben, in welchem Fall Git versuchen wird, einen auf die gleiche Weise wie für andere Anmeldeinformationen zu beschaffen. Siehe gitcredentials[7] für weitere Informationen. Die Syntax lautet daher [protocol://][user[:password]@]proxyhost[:port][/path]. Dies kann pro Remote-Verbindung überschrieben werden; siehe remote.<name>.proxy.

Legt die Methode fest, mit der gegen den HTTP-Proxy authentifiziert wird. Dies wird nur wirksam, wenn die konfigurierte Proxy-Zeichenkette einen Benutzernamen enthält (d. h. die Form user@host oder user@host:port hat). Dies kann pro Remote-Verbindung überschrieben werden; siehe remote.<name>.proxyAuthMethod. Beides kann durch die Umgebungsvariable GIT_HTTP_PROXY_AUTHMETHOD überschrieben werden. Mögliche Werte sind:

Der Pfad zu einer Datei, die ein Client-Zertifikat zur Authentifizierung bei einem HTTPS-Proxy speichert. Kann durch die Umgebungsvariable GIT_PROXY_SSL_CERT überschrieben werden.

Der Pfad zu einer Datei, die einen privaten Schlüssel zur Authentifizierung bei einem HTTPS-Proxy speichert. Kann durch die Umgebungsvariable GIT_PROXY_SSL_KEY überschrieben werden.

Aktiviert die Passwortabfrage von Git für das Proxy-SSL-Zertifikat. Andernfalls wird OpenSSL den Benutzer möglicherweise mehrmals auffordern, wenn das Zertifikat oder der private Schlüssel verschlüsselt ist. Kann durch die Umgebungsvariable GIT_PROXY_SSL_CERT_PASSWORD_PROTECTED überschrieben werden.

Pfad zu der Datei, die das Zertifikatspaket enthält, das zur Verifizierung des Proxys bei Verwendung eines HTTPS-Proxys verwendet werden soll. Kann durch die Umgebungsvariable GIT_PROXY_SSL_CAINFO überschrieben werden.