English ▾ Themen ▾ Neueste Version ▾ git-fetch zuletzt aktualisiert in 2.52.0

NAME

git-fetch - Lade Objekte und Refs aus einem anderen Repository herunter

SYNOPSIS

git fetch [<options>] [<repository> [<refspec>…​]]
git fetch [<options>] <group>
git fetch --multiple [<options>] [(<repository> | <group>)…​]
git fetch --all [<options>]

BESCHREIBUNG

Lade Branches und/oder Tags (zusammenfassend "Refs") aus einem oder mehreren anderen Repositories herunter, zusammen mit den Objekten, die zur Vervollständigung ihrer Historien benötigt werden. Remote-Tracking-Branches werden aktualisiert (siehe die Beschreibung von <refspec> unten für Möglichkeiten, dieses Verhalten zu steuern).

Standardmäßig werden auch alle Tags, die auf die heruntergeladenen Historien verweisen, heruntergeladen. Der Effekt ist, dass Tags, die auf Branches verweisen, an denen Sie interessiert sind, heruntergeladen werden. Dieses Standardverhalten kann mit den Optionen --tags oder --no-tags oder durch die Konfiguration remote.<name>.tagOpt geändert werden. Durch die explizite Verwendung einer Refspec, die Tags herunterlädt, können Sie auch Tags herunterladen, die nicht auf Branches verweisen, an denen Sie interessiert sind.

git fetch kann entweder aus einem einzelnen benannten Repository oder einer URL beziehen, oder aus mehreren Repositories gleichzeitig, wenn <group> angegeben ist und es einen remotes.<group>-Eintrag in der Konfigurationsdatei gibt. (Siehe git-config[1]).

Wenn kein Remote angegeben ist, wird standardmäßig das origin Remote verwendet, es sei denn, für den aktuellen Branch ist ein Upstream-Branch konfiguriert.

Die Namen der heruntergeladenen Refs, zusammen mit den Objekt-Namen, auf die sie verweisen, werden in .git/FETCH_HEAD geschrieben. Diese Informationen können von Skripten oder anderen Git-Befehlen, wie z.B. git-pull[1], verwendet werden.

OPTIONEN

--all
--no-all

Ruft alle Remotes ab, außer denen, bei denen die Konfigurationsvariable remote.<name>.skipFetchAll gesetzt ist. Dies überschreibt die Konfigurationsvariable fetch.all.

-a
--append

Hängt Ref-Namen und Objekt-Namen der heruntergeladenen Refs an den bestehenden Inhalt von .git/FETCH_HEAD an. Ohne diese Option werden alte Daten in .git/FETCH_HEAD überschrieben.

--atomic

Verwendet eine atomare Transaktion, um lokale Refs zu aktualisieren. Entweder werden alle Refs aktualisiert, oder im Fehlerfall werden keine Refs aktualisiert.

--depth=<tiefe>

Beschränkt das Abrufen auf die angegebene Anzahl von Commits von der Spitze jeder Remote-Branch-Historie. Wenn in ein *flaches* Repository geklont wird, das mit der Option git clone --depth=<tiefe> erstellt wurde (siehe git-clone[1]), wird die Historie auf die angegebene Anzahl von Commits vertieft oder verkürzt. Tags für die vertieften Commits werden nicht heruntergeladen.

--deepen=<tiefe>

Ähnlich wie --depth, außer dass es die Anzahl der Commits von der aktuellen flachen Grenze anstelle von der Spitze jeder Remote-Branch-Historie angibt.

--shallow-since=<datum>

Vertieft oder verkürzt die Historie eines flachen Repositorys, um alle erreichbaren Commits nach <datum> einzuschließen.

--shallow-exclude=<ref>

Vertieft oder verkürzt die Historie eines flachen Repositorys, um Commits auszuschließen, die von einem angegebenen Remote-Branch oder Tag erreichbar sind. Diese Option kann mehrfach angegeben werden.

--unshallow

Wenn das Quell-Repository vollständig ist, konvertiert ein flaches Repository in ein vollständiges und entfernt alle Beschränkungen, die durch flache Repositories auferlegt werden.

Wenn das Quell-Repository flach ist, werden so viele Objekte wie möglich heruntergeladen, damit das aktuelle Repository die gleiche Historie wie das Quell-Repository hat.

--update-shallow

Beim Abrufen aus einem flachen Repository lehnt git fetch standardmäßig Refs ab, die eine Aktualisierung von .git/shallow erfordern. Diese Option aktualisiert .git/shallow und akzeptiert solche Refs.

--negotiation-tip=<commit|glob>

Standardmäßig meldet Git dem Server Commits, die von allen lokalen Refs erreichbar sind, um gemeinsame Commits zu finden und die Größe des zu empfangenden Packfiles zu reduzieren. Wenn angegeben, meldet Git nur Commits, die von den angegebenen Spitzen erreichbar sind. Dies ist nützlich, um Abrufe zu beschleunigen, wenn der Benutzer weiß, welche lokale Ref wahrscheinlich gemeinsame Commits mit der abgerufenen Upstream-Ref hat.

Diese Option kann mehrfach angegeben werden; in diesem Fall meldet Git Commits, die von einem der angegebenen Commits erreichbar sind.

Das Argument für diese Option kann ein Glob über Ref-Namen, eine Ref oder der (möglicherweise abgekürzte) SHA-1 eines Commits sein. Die Angabe eines Globs entspricht der mehrfachen Angabe dieser Option für jeden übereinstimmenden Ref-Namen.

Siehe auch die Konfigurationsvariablen fetch.negotiationAlgorithm und push.negotiate, die in git-config[1] dokumentiert sind, sowie die Option --negotiate-only unten.

--negotiate-only

Holt nichts vom Server, sondern gibt die Vorfahren der angegebenen --negotiation-tip=* Argumente aus, die wir mit dem Server gemeinsam haben.

Dies ist inkompatibel mit --recurse-submodules=[yes|on-demand]. Intern wird dies zur Implementierung der Option push.negotiate verwendet, siehe git-config[1].

--dry-run

Zeigt an, was getan würde, ohne Änderungen vorzunehmen.

--porcelain

Gibt die Ausgabe auf der Standardausgabe in einem leicht zu parsenden Format für Skripte aus. Siehe Abschnitt AUSGABE in git-fetch[1] für Details.

Dies ist inkompatibel mit --recurse-submodules=[yes|on-demand] und hat Vorrang vor der Konfigurationsoption fetch.output.

--write-fetch-head
--no-write-fetch-head

Schreibt die Liste der heruntergeladenen Remote-Refs in die Datei FETCH_HEAD direkt unter $GIT_DIR. Dies ist die Standardeinstellung. Die Übergabe von --no-write-fetch-head auf der Befehlszeile weist Git an, die Datei nicht zu schreiben. Unter der Option --dry-run wird die Datei niemals geschrieben.

-f
--force

Wenn git fetch mit der Refspec <src>:<dst> verwendet wird, kann es die Aktualisierung des lokalen Branches ablehnen, wie im Teil <refspec> unten erläutert. Diese Option überschreibt diese Prüfung.

-k
--keep

Heruntergeladenes Pack behalten.

--multiple

Erlaubt die Angabe mehrerer Argumente vom Typ <repository> und <group>. Keine <refspec>s dürfen angegeben werden.

--auto-maintenance
--no-auto-maintenance
--auto-gc
--no-auto-gc

Führt git maintenance run --auto am Ende aus, um bei Bedarf eine automatische Repository-Wartung durchzuführen. (--[no-]auto-gc ist ein Synonym.) Dies ist standardmäßig aktiviert.

--write-commit-graph
--no-write-commit-graph

Schreibt nach dem Abrufen einen Commit-Graph. Dies überschreibt die Konfigurationseinstellung fetch.writeCommitGraph.

--prefetch

Ändert die konfigurierte Refspec, um alle Refs im Namensraum refs/prefetch/ zu platzieren. Siehe die Aufgabe prefetch in git-maintenance[1].

-p
--prune

Vor dem Abrufen werden alle Remote-Tracking-Referenzen entfernt, die auf dem Remote nicht mehr vorhanden sind. Tags werden nicht beschnitten, wenn sie nur aufgrund der standardmäßigen Tag-Autoverfolgung oder aufgrund der Option --tags abgerufen werden. Wenn Tags jedoch aufgrund einer expliziten Refspec abgerufen werden (entweder auf der Befehlszeile oder in der Remote-Konfiguration, z.B. wenn das Remote mit der Option --mirror geklont wurde), werden sie ebenfalls beschnitten. Die Angabe von --prune-tags ist eine Kurzform für die Angabe der Tag-Refspec.

Siehe den Abschnitt PRUNING unten für weitere Details.

-P
--prune-tags

Vor dem Abrufen werden alle lokalen Tags entfernt, die auf dem Remote nicht mehr vorhanden sind, wenn --prune aktiviert ist. Diese Option sollte mit mehr Vorsicht verwendet werden, im Gegensatz zu --prune entfernt sie alle lokalen Referenzen (lokale Tags), die erstellt wurden. Diese Option ist eine Kurzform für die explizite Angabe der Tag-Refspec zusammen mit --prune, siehe die Diskussion darüber in seiner Dokumentation.

Siehe den Abschnitt PRUNING unten für weitere Details.

-n
--no-tags

Standardmäßig werden Tags, die auf Objekte verweisen, die aus dem Remote-Repository heruntergeladen werden, abgerufen und lokal gespeichert. Diese Option deaktiviert diese automatische Tag-Verfolgung. Das Standardverhalten für ein Remote kann mit der Einstellung remote.<name>.tagOpt angegeben werden. Siehe git-config[1].

--refetch

Anstatt mit dem Server zu verhandeln, um die Übertragung von Commits und zugehörigen Objekten zu vermeiden, die bereits lokal vorhanden sind, ruft diese Option alle Objekte ab, wie ein frisches Klonen. Verwenden Sie dies, um einen Filter für partielle Klone aus der Konfiguration oder mit --filter= erneut anzuwenden, wenn sich die Filterdefinition geändert hat. Die automatische Wartung nach dem Abrufen führt eine Konsolidierung der Objektdatenbank durch, um Duplikate zu entfernen.

--refmap=<refspec>

Beim Abrufen von auf der Befehlszeile aufgeführten Refs wird die angegebene Refspec (kann mehrfach angegeben werden) verwendet, um die Refs auf Remote-Tracking-Branches abzubilden, anstatt der Werte der Konfigurationsvariablen remote.*.fetch für das Remote-Repository. Die Angabe einer leeren refspec für die Option --refmap bewirkt, dass Git die konfigurierten Refspecs ignoriert und sich ausschließlich auf die als Befehlszeilenargumente bereitgestellten Refspecs verlässt. Siehe den Abschnitt "Konfigurierte Remote-Tracking-Branches" für Details.

-t
--tags

Ruft alle Tags vom Remote ab (d.h. ruft Remote-Tags refs/tags/* in lokale Tags mit demselben Namen ab), zusätzlich zu allem, was sonst noch abgerufen würde. Die Verwendung dieser Option allein unterliegt keinem Pruning, auch wenn --prune verwendet wird (obwohl Tags trotzdem beschnitten werden können, wenn sie auch das Ziel einer expliziten Refspec sind; siehe --prune).

--recurse-submodules[=(yes|on-demand|no)]

Diese Option steuert, ob und unter welchen Bedingungen neue Commits von Submodulen ebenfalls abgerufen werden sollen. Beim Durchlaufen von Submodulen versucht git fetch immer, "geänderte" Submodule abzurufen, d.h. ein Submodul, das Commits enthält, auf die ein neu abgerufener Superprojekt-Commit verweist, die aber im lokalen Submodul-Klon fehlen. Ein geändertes Submodul kann abgerufen werden, solange es lokal vorhanden ist, z.B. in $GIT_DIR/modules/ (siehe gitsubmodules[7]); wenn der Upstream ein neues Submodul hinzufügt, kann dieses Submodul nicht abgerufen werden, bis es z.B. durch git submodule update geklont wurde.

Wenn auf on-demand gesetzt, werden nur geänderte Submodule abgerufen. Wenn auf yes gesetzt, werden alle bevölkerten Submodule abgerufen und Submodule, die sowohl unvervölkert als auch geändert sind, werden abgerufen. Wenn auf no gesetzt, werden Submodule niemals abgerufen.

Wenn nicht spezifiziert, wird der Wert von fetch.recurseSubmodules verwendet, falls dieser gesetzt ist (siehe git-config[1]), und standardmäßig auf on-demand gesetzt, falls nicht gesetzt. Wenn diese Option ohne Wert verwendet wird, ist der Standardwert yes.

-j
--jobs=<n>

Anzahl paralleler Kinder, die für alle Formen des Abrufs verwendet werden sollen.

Wenn die Option --multiple angegeben wurde, werden die verschiedenen Remotes parallel abgerufen. Wenn mehrere Submodule abgerufen werden, werden diese parallel abgerufen. Um sie unabhängig zu steuern, verwenden Sie die Konfigurationseinstellungen fetch.parallel und submodule.fetchJobs (siehe git-config[1]).

Typischerweise sind parallele rekursive und Multi-Remote-Abrufe schneller. Standardmäßig werden Abrufe sequenziell, nicht parallel, durchgeführt.

--no-recurse-submodules

Deaktiviert rekursives Abrufen von Submodulen (dies hat die gleiche Wirkung wie die Option --recurse-submodules=no).

--set-upstream

Wenn das Remote erfolgreich abgerufen wird, wird eine Upstream-Referenz (Tracking-Referenz) hinzugefügt, die von einem argumentlosen git-pull[1] und anderen Befehlen verwendet wird. Für weitere Informationen siehe branch.<name>.merge und branch.<name>.remote in git-config[1].

--submodule-prefix=<pfad>

Fügt <pfad> den Pfaden hinzu, die in informativen Meldungen wie "Fetching submodule foo" angezeigt werden. Diese Option wird intern verwendet, wenn über Submodule rekursiv gegangen wird.

--recurse-submodules-default=[yes|on-demand]

Diese Option wird intern verwendet, um vorübergehend einen nicht-negativen Standardwert für die Option --recurse-submodules bereitzustellen. Alle anderen Methoden zur Konfiguration der Submodul-Rekursion von fetch (wie Einstellungen in gitmodules[5] und git-config[1]) überschreiben diese Option, ebenso wie die direkte Angabe von --[no-]recurse-submodules.

-u
--update-head-ok

Standardmäßig lehnt git fetch die Aktualisierung des Heads, der dem aktuellen Branch entspricht, ab. Dieses Flag deaktiviert die Prüfung. Dies dient rein dem internen Gebrauch für git pull zur Kommunikation mit git fetch, und es sei denn, Sie implementieren Ihre eigene Porcelain, sollten Sie es nicht verwenden.

--upload-pack <upload-pack>

Wenn angegeben und das abzurufende Repository von git fetch-pack behandelt wird, wird --exec=<upload-pack> an den Befehl übergeben, um einen nicht standardmäßigen Pfad für den auf der anderen Seite ausgeführten Befehl anzugeben.

-q
--quiet

Übergibt --quiet an git-fetch-pack und unterdrückt alle anderen intern verwendeten Git-Befehle. Der Fortschritt wird nicht auf den Standardfehlerausgabestrom gemeldet.

-v
--verbose

Ausführlich sein.

--progress

Der Fortschrittsstatus wird standardmäßig auf dem Standardfehlerausgabestrom berichtet, wenn dieser an ein Terminal angeschlossen ist, es sei denn, -q wird angegeben. Diese Flag erzwingt die Anzeige des Fortschrittsstatus, auch wenn der Standardfehlerausgabestrom nicht an ein Terminal weitergeleitet wird.

-o <option>
--server-option=<option>

Überträgt die angegebene Zeichenkette an den Server bei der Kommunikation mit Protokollversion 2. Die angegebene Zeichenkette darf keine NUL- oder LF-Zeichen enthalten. Die Handhabung von Server-Optionen durch den Server, einschließlich unbekannter, ist serverspezifisch. Wenn mehrere --server-option=<option> angegeben werden, werden sie alle in der auf der Befehlszeile angegebenen Reihenfolge an die Gegenseite gesendet. Wenn keine --server-option=<option> von der Befehlszeile angegeben wird, werden stattdessen die Werte der Konfigurationsvariablen remote.<name>.serverOption verwendet.

--show-forced-updates

Standardmäßig prüft git, ob ein Branch während des Abrufs zwangsaktualisiert wird. Dies kann über fetch.showForcedUpdates deaktiviert werden, aber die Option --show-forced-updates garantiert, dass diese Prüfung durchgeführt wird. Siehe git-config[1].

--no-show-forced-updates

Standardmäßig prüft git, ob ein Branch während des Abrufs zwangsaktualisiert wird. Übergabe von --no-show-forced-updates oder Setzen von fetch.showForcedUpdates auf false, um diese Prüfung aus Leistungsgründen zu überspringen. Wenn während git-pull verwendet, prüft die Option --ff-only immer noch auf zwangsweise Aktualisierungen, bevor ein Fast-Forward-Update versucht wird. Siehe git-config[1].

-4
--ipv4

Nur IPv4-Adressen verwenden, IPv6-Adressen ignorieren.

-6
--ipv6

Nur IPv6-Adressen verwenden, IPv4-Adressen ignorieren.

<repository>

Das "Remote"-Repository, das die Quelle für eine Fetch- oder Pull-Operation ist. Dieser Parameter kann entweder eine URL sein (siehe Abschnitt GIT URLS unten) oder der Name eines Remotes (siehe Abschnitt REMOTES unten).

<group>

Ein Name, der sich auf eine Liste von Repositories als Wert von remotes.<group> in der Konfigurationsdatei bezieht. (Siehe git-config[1]).

<refspec>

Gibt an, welche Refs abgerufen und welche lokalen Refs aktualisiert werden sollen. Wenn keine refspecs auf der Befehlszeile erscheinen, werden die abzurufenden Refs stattdessen aus den remote.repository.fetch Variablen gelesen (siehe KONFIGURIERTE REMOTE-TRACKING-BRANCHES unten).

Das Format eines refspec-Parameters ist ein optionales Plus +, gefolgt von der Quelle <src>, gefolgt von einem Doppelpunkt :, gefolgt vom Ziel <dst>. Der Doppelpunkt kann weggelassen werden, wenn <dst> leer ist. <src> ist typischerweise eine Ref, oder ein Glob-Muster mit einem einzelnen *, das zum Abgleichen einer Gruppe von Refs verwendet wird, es kann aber auch ein vollständig ausgeschriebener Hex-Objektname sein.

Eine refspec kann ein * in ihrer <src> enthalten, um einen einfachen Mustervergleich anzuzeigen. Eine solche Refspec funktioniert wie ein Glob, der jede Ref mit dem Muster abgleicht. Eine Muster-refspec muss genau ein * sowohl in <src> als auch in <dst> haben. Sie ordnet Refs dem Ziel zu, indem sie das * durch den abgeglichenen Inhalt aus der Quelle ersetzt.

Wenn eine Refspec mit ^ präfigiert wird, wird sie als negative Refspec interpretiert. Anstatt anzugeben, welche Refs abgerufen werden sollen oder welche lokalen Refs aktualisiert werden sollen, gibt eine solche Refspec stattdessen zu ignorierende Refs an. Eine Ref wird als übereinstimmend betrachtet, wenn sie mindestens einer positiven Refspec entspricht und keiner negativen Refspec. Negative Refspecs können nützlich sein, um den Geltungsbereich einer Muster-Refspec einzuschränken, damit sie bestimmte Refs nicht einschließt. Negative Refspecs können selbst Muster-Refspecs sein. Sie dürfen jedoch nur eine <src> enthalten und keine <dst> angeben. Vollständig ausgeschriebene Hex-Objektnamen werden ebenfalls nicht unterstützt.

tag <tag> bedeutet dasselbe wie refs/tags/<tag>:refs/tags/<tag>; sie fordert das Abrufen von allem bis zum angegebenen Tag an.

Die Remote-Ref, die mit <src> übereinstimmt, wird abgerufen, und wenn <dst> keine leere Zeichenkette ist, wird versucht, die lokale Ref, die damit übereinstimmt, zu aktualisieren.

Ob diese Aktualisierung ohne --force zulässig ist, hängt vom Namensraum der Ref ab, zu dem abgerufen wird, vom Typ des abgerufenen Objekts und davon, ob die Aktualisierung als Fast-Forward betrachtet wird. Im Allgemeinen gelten die gleichen Regeln für das Abrufen wie beim Pushen, siehe den Abschnitt refspec... von git-push[1] für diese Regeln. Ausnahmen von diesen Regeln, die spezifisch für git fetch sind, werden unten aufgeführt.

Bis Git-Version 2.20 und im Gegensatz zum Pushen mit git-push[1] wurden alle Aktualisierungen von refs/tags/* ohne + in der Refspec (oder --force) akzeptiert. Beim Abrufen wurden wir promiskuitiv alle Tag-Aktualisierungen von einem Remote als erzwungene Abrufe betrachtet. Seit Git-Version 2.20 funktioniert das Abrufen zur Aktualisierung von refs/tags/* genauso wie beim Pushen. D.h. alle Aktualisierungen werden ohne + in der Refspec (oder --force) abgelehnt.

Im Gegensatz zum Pushen mit git-push[1] werden alle Aktualisierungen außerhalb von refs/{tags,heads}/* ohne + in der Refspec (oder --force) akzeptiert, sei es das Austauschen von z.B. einem Baumobjekt gegen ein Blob, oder eines Commits gegen einen anderen Commit, der nicht den vorherigen Commit als Vorfahren hat usw.

Im Gegensatz zum Pushen mit git-push[1] gibt es keine Konfiguration, die diese Regeln ändert, und nichts Ähnliches wie ein pre-fetch Hook analog zum pre-receive Hook.

Wie beim Pushen mit git-push[1] können alle oben beschriebenen Regeln darüber, was als Aktualisierung nicht erlaubt ist, durch Hinzufügen eines optionalen führenden + zu einer Refspec (oder durch Verwendung der Befehlszeilenoption --force) außer Kraft gesetzt werden. Die einzige Ausnahme ist, dass kein Zwang den Namensraum refs/heads/* dazu bringen kann, ein Nicht-Commit-Objekt zu akzeptieren.

Hinweis
 Wenn der Remote-Branch, den Sie abrufen möchten, bekanntermaßen regelmäßig zurückgesetzt und neu basiert wird, ist es zu erwarten, dass seine neue Spitze kein Nachfahre seiner vorherigen Spitze ist (wie sie in Ihrem Remote-Tracking-Branch beim letzten Abruf gespeichert wurde). Sie möchten das +-Zeichen verwenden, um anzuzeigen, dass für solche Branches nicht-Fast-Forward-Aktualisierungen erforderlich sind. Es gibt keine Möglichkeit zu bestimmen oder zu deklarieren, dass ein Branch in einem Repository mit diesem Verhalten verfügbar gemacht wird; der abrufende Benutzer muss einfach wissen, dass dies das erwartete Nutzungsmuster für einen Branch ist.
--stdin

Liest Refspecs, eine pro Zeile, von stdin zusätzlich zu den als Argumenten bereitgestellten. Das Format "tag <name>" wird nicht unterstützt.

GIT URLS

Im Allgemeinen enthalten URLs Informationen über das Transportprotokoll, die Adresse des Remote-Servers und den Pfad zum Repository. Abhängig vom Transportprotokoll können einige dieser Informationen fehlen.

Git unterstützt ssh, git, http und https Protokolle (zusätzlich können ftp und ftps zum Abrufen verwendet werden, aber das ist ineffizient und veraltet; verwenden Sie sie nicht).

Der native Transport (d.h. git:// URL) führt keine Authentifizierung durch und sollte mit Vorsicht in ungesicherten Netzwerken verwendet werden.

Die folgenden Syntaxe können damit verwendet werden

  • ssh://[<user>@]<host>[:<port>]/<pfad-zum-git-repo>

  • git://<host>[:<port>]/<pfad-zum-git-repo>

  • http[s]://<host>[:<port>]/<pfad-zum-git-repo>

  • ftp[s]://<host>[:<port>]/<pfad-zum-git-repo>

Eine alternative scp-ähnliche Syntax kann auch mit dem ssh-Protokoll verwendet werden

  • [<user>@]<host>:/<pfad-zum-git-repo>

Diese Syntax wird nur erkannt, wenn keine Schrägstriche vor dem ersten Doppelpunkt stehen. Dies hilft, einen lokalen Pfad, der einen Doppelpunkt enthält, zu unterscheiden. Zum Beispiel kann der lokale Pfad foo:bar als absoluter Pfad oder ./foo:bar angegeben werden, um eine Fehlinterpretation als ssh-URL zu vermeiden.

Die Protokolle ssh und git unterstützen zusätzlich die Erweiterung von ~<username>

  • ssh://[<user>@]<host>[:<port>]/~<user>/<pfad-zum-git-repo>

  • git://<host>[:<port>]/~<user>/<pfad-zum-git-repo>

  • [<user>@]<host>:~<user>/<pfad-zum-git-repo>

Für lokale Repositories, die ebenfalls nativ von Git unterstützt werden, können die folgenden Syntaxe verwendet werden

  • /pfad/zu/repo.git/

  • file:///pfad/zu/repo.git/

Diese beiden Syntaxe sind weitgehend äquivalent, außer beim Klonen, wenn die erste die Option --local impliziert. Siehe git-clone[1] für Details.

git clone, git fetch und git pull, aber nicht git push, akzeptieren auch eine geeignete Bundle-Datei. Siehe git-bundle[1].

Wenn Git ein bestimmtes Transportprotokoll nicht handhaben kann, versucht es, den Remote-Helfer remote-<transport> zu verwenden, falls einer existiert. Um explizit einen Remote-Helfer anzufordern, kann die folgende Syntax verwendet werden

  • <transport>::<adresse>

wobei <adresse> ein Pfad, ein Server und Pfad oder eine beliebige URL-ähnliche Zeichenkette sein kann, die vom spezifischen aufgerufenen Remote-Helfer erkannt wird. Siehe gitremote-helpers[7] für Details.

Wenn es eine große Anzahl ähnlich benannter Remote-Repositories gibt und Sie ein anderes Format dafür verwenden möchten (so dass die von Ihnen verwendeten URLs in URLs umgeschrieben werden, die funktionieren), können Sie einen Konfigurationsabschnitt der Form erstellen

	[url "<actual-url-base>"]
		insteadOf = <other-url-base>

Zum Beispiel, mit diesem

	[url "git://git.host.xz/"]
		insteadOf = host.xz:/path/to/
		insteadOf = work:

eine URL wie "work:repo.git" oder "host.xz:/path/to/repo.git" wird in jedem Kontext, der eine URL entgegennimmt, zu "git://git.host.xz/repo.git" umgeschrieben.

Wenn Sie URLs nur für Push-Operationen umschreiben möchten, können Sie einen Konfigurationsabschnitt der Form erstellen

	[url "<actual-url-base>"]
		pushInsteadOf = <other-url-base>

Zum Beispiel, mit diesem

	[url "ssh://example.org/"]
		pushInsteadOf = git://example.org/

eine URL wie "git://example.org/path/to/repo.git" wird für Push-Operationen zu "ssh://example.org/path/to/repo.git" umgeschrieben, aber Pull-Operationen verwenden weiterhin die ursprüngliche URL.

REMOTES

Der Name eines der folgenden kann anstelle einer URL als Argument repository verwendet werden

  • ein Remote in der Git-Konfigurationsdatei: $GIT_DIR/config,

  • eine Datei im Verzeichnis $GIT_DIR/remotes oder

  • eine Datei im Verzeichnis $GIT_DIR/branches.

All dies erlaubt Ihnen auch, die Refspec von der Kommandozeile wegzulassen, da jede dieser Dateien eine Refspec enthält, die Git standardmäßig verwendet.

Benannter Remote in der Konfigurationsdatei

Sie können den Namen eines Remotes angeben, den Sie zuvor mit git-remote[1], git-config[1] oder durch manuelle Bearbeitung der Datei $GIT_DIR/config konfiguriert haben. Die URL dieses Remotes wird verwendet, um auf das Repository zuzugreifen. Die Refspec dieses Remotes wird standardmäßig verwendet, wenn Sie keine Refspec auf der Kommandozeile angeben. Der Eintrag in der Konfigurationsdatei würde wie folgt aussehen:

	[remote "<name>"]
		url = <URL>
		pushurl = <pushurl>
		push = <refspec>
		fetch = <refspec>

Die <pushurl> wird nur für Pushes verwendet. Sie ist optional und standardmäßig <URL>. Das Pushen zu einem Remote betrifft alle definierten Push-URLs oder alle definierten URLs, wenn keine Push-URLs definiert sind. Fetch hingegen holt nur von der ersten definierten URL, wenn mehrere URLs definiert sind.

Benannte Datei in $GIT_DIR/remotes

Sie können den Namen einer Datei in $GIT_DIR/remotes angeben. Die URL in dieser Datei wird verwendet, um auf das Repository zuzugreifen. Die Refspec in dieser Datei wird als Standard verwendet, wenn Sie keine Refspec auf der Kommandozeile angeben. Diese Datei sollte folgendes Format haben:

	URL: one of the above URL formats
	Push: <refspec>
	Pull: <refspec>

Push: Zeilen werden von git push verwendet und Pull: Zeilen werden von git pull und git fetch verwendet. Mehrere Push: und Pull: Zeilen können für zusätzliche Branch-Mappings angegeben werden.

Benannte Datei in $GIT_DIR/branches

Sie können den Namen einer Datei in $GIT_DIR/branches angeben. Die URL in dieser Datei wird verwendet, um auf das Repository zuzugreifen. Diese Datei sollte folgendes Format haben:

	<URL>#<head>

<URL> ist erforderlich; #<head> ist optional.

Abhängig vom Vorgang verwendet Git eine der folgenden Refspecs, wenn Sie keine auf der Kommandozeile angeben. <branch> ist der Name dieser Datei in $GIT_DIR/branches und <head> standardmäßig master.

git fetch verwendet

	refs/heads/<head>:refs/heads/<branch>

git push verwendet

	HEAD:refs/heads/<head>

UPSTREAM BRANCHES

Branches in Git können optional einen Upstream-Remote-Branch haben. Git verwendet standardmäßig den Upstream-Branch für Remote-Operationen, z. B.

  • Dies ist der Standard für git pull oder git fetch ohne Argumente.

  • Dies ist der Standard für git push ohne Argumente, mit einigen Ausnahmen. Sie können zum Beispiel die Option branch.<name>.pushRemote verwenden, um zu einem anderen Remote zu pushen, als von dem Sie ziehen, und standardmäßig mit push.default=simple muss der von Ihnen konfigurierte Upstream-Branch denselben Namen haben.

  • Verschiedene Befehle, einschließlich git checkout und git status, zeigen Ihnen, wie viele Commits zu Ihrem aktuellen Branch und zum Upstream hinzugefügt wurden, seitdem Sie ihn verzweigt haben, z. B. "Your branch and origin/main have diverged, and have 2 and 3 different commits each respectively".

Der Upstream wird in .git/config in den Feldern "remote" und "merge" gespeichert. Wenn zum Beispiel main's Upstream origin/main ist

[branch "main"]
   remote = origin
   merge = refs/heads/main

Sie können einen Upstream-Branch explizit mit git push --set-upstream <remote> <branch> festlegen, aber Git legt den Upstream oft automatisch für Sie fest, zum Beispiel

  • Wenn Sie ein Repository klonen, setzt Git den Upstream für den Standard-Branch automatisch.

  • Wenn die Konfigurationsoption push.autoSetupRemote gesetzt ist, setzt git push den Upstream automatisch beim ersten Push eines Branches.

  • Das Auschecken eines Remote-Tracking-Branches mit git checkout <branch> erstellt automatisch einen lokalen Branch mit diesem Namen und setzt den Upstream auf den Remote-Branch.

Hinweis
 Upstream-Branches werden manchmal als "Tracking-Informationen" bezeichnet, wie in "set the branch’s tracking information".

KONFIGURIERTE REMOTE-TRACKING-BRANCHES

Sie interagieren oft mit demselben Remote-Repository, indem Sie regelmäßig und wiederholt davon holen. Um den Fortschritt eines solchen Remote-Repositorys zu verfolgen, erlaubt Ihnen git fetch, remote.<repository>.fetch Konfigurationsvariablen zu konfigurieren.

Typischerweise sieht eine solche Variable so aus:

[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*

Diese Konfiguration wird auf zwei Arten verwendet:

  • Wenn git fetch ohne Angabe von Branches und/oder Tags zum Holen auf der Kommandozeile ausgeführt wird, z. B. git fetch origin oder git fetch, werden die Werte von remote.<repository>.fetch als Refspecs verwendet – sie geben an, welche Refs geholt und welche lokalen Refs aktualisiert werden sollen. Das obige Beispiel holt alle Branches, die im origin existieren (d. h. jede Ref, die mit der linken Seite des Werts übereinstimmt, refs/heads/*) und aktualisiert die entsprechenden Remote-Tracking-Branches in der Hierarchie refs/remotes/origin/*.

  • Wenn git fetch mit expliziten Branches und/oder Tags zum Holen auf der Kommandozeile ausgeführt wird, z. B. git fetch origin master, bestimmen die auf der Kommandozeile angegebenen <refspec>s, was geholt wird (z. B. master im Beispiel, was eine Kurzform für master: ist, was wiederum bedeutet "hole den master-Branch, aber ich sage nicht explizit, welchen Remote-Tracking-Branch ich damit von der Kommandozeile aktualisieren soll"), und der Beispielbefehl holt *nur* den master-Branch. Die Werte von remote.<repository>.fetch bestimmen, welcher Remote-Tracking-Branch, falls vorhanden, aktualisiert wird. Wenn sie auf diese Weise verwendet werden, haben die Werte von remote.<repository>.fetch keine Auswirkung auf die Entscheidung, *was* geholt wird (d. h. die Werte werden nicht als Refspecs verwendet, wenn die Kommandozeile Refspecs auflistet); sie werden nur verwendet, um zu entscheiden, *wo* die geholten Refs gespeichert werden, indem sie als Mapping dienen.

Die letztere Verwendung der Werte von remote.<repository>.fetch kann durch Angabe des Parameters --refmap=<refspec> auf der Kommandozeile überschrieben werden.

PRUNING

Git hat die Standardeinstellung, Daten zu behalten, es sei denn, sie werden explizit weggeworfen; dies gilt auch für lokale Referenzen auf Branches in Remotes, die diese Branches selbst gelöscht haben.

Wenn diese sich ansammeln, können diese veralteten Referenzen die Leistung in großen und geschäftigen Repos mit viel Branch-Churn verschlechtern und z. B. die Ausgabe von Befehlen wie git branch -a --contains <commit> unnötig ausführlich machen, sowie alles andere beeinflussen, das mit dem vollständigen Satz bekannter Referenzen arbeitet.

Diese Remote-Tracking-Referenzen können einmalig mit einem der folgenden Befehle gelöscht werden:

# While fetching
$ git fetch --prune <name>

# Only prune, don't fetch
$ git remote prune <name>

Um Referenzen als Teil Ihres normalen Arbeitsablaufs zu bereinigen, ohne sich daran erinnern zu müssen, dies auszuführen, setzen Sie fetch.prune global oder remote.<name>.prune pro Remote in der Konfiguration. Siehe git-config[1].

Hier wird es knifflig und spezifischer. Die Pruning-Funktion kümmert sich eigentlich nicht um Branches, stattdessen bereinigt sie lokale ←→ Remote-Referenzen als Funktion der Refspec des Remotes (siehe <refspec> und CONFIGURED REMOTE-TRACKING BRANCHES oben).

Daher werden, wenn die Refspec für das Remote z. B. refs/tags/*:refs/tags/* enthält oder Sie manuell z. B. git fetch --prune <name> "refs/tags/*:refs/tags/*" ausführen, nicht veraltete Remote-Tracking-Branches gelöscht, sondern lokale Tags, die nicht im Remote existieren.

Dies ist möglicherweise nicht das, was Sie erwarten, d. h. Sie möchten das Remote <name> bereinigen, aber auch explizit Tags davon abrufen, sodass Sie beim Abrufen von ihm alle Ihre lokalen Tags löschen, von denen die meisten möglicherweise nicht einmal vom Remote <name> stammen.

Seien Sie daher vorsichtig, wenn Sie dies mit einer Refspec wie refs/tags/*:refs/tags/* oder einer anderen Refspec verwenden, die Referenzen von mehreren Remotes demselben lokalen Namensraum zuordnen könnte.

Da das Aktualisieren von Branches und Tags im Remote ein häufiger Anwendungsfall ist, kann die Option --prune-tags zusammen mit --prune übergeben werden, um lokale Tags zu bereinigen, die im Remote nicht vorhanden sind, und Tags, die sich unterscheiden, zu erzwingen. Tag-Bereinigung kann auch mit fetch.pruneTags oder remote.<name>.pruneTags in der Konfiguration aktiviert werden. Siehe git-config[1].

Die Option --prune-tags ist gleichbedeutend mit der Angabe von refs/tags/*:refs/tags/* in den Refspecs des Remotes. Dies kann zu einigen scheinbar seltsamen Interaktionen führen.

# These both fetch tags
$ git fetch --no-tags origin 'refs/tags/*:refs/tags/*'
$ git fetch --no-tags --prune-tags origin

Der Grund, warum keine Fehlermeldung ausgegeben wird, wenn sie ohne --prune oder seine Konfigurationsversionen angegeben wird, ist die Flexibilität der konfigurierten Versionen und die Beibehaltung einer 1:1-Zuordnung zwischen dem, was die Kommandozeilen-Flags tun, und dem, was die Konfigurationsversionen tun.

Es ist zum Beispiel sinnvoll, fetch.pruneTags=true in ~/.gitconfig zu konfigurieren, um Tags zu bereinigen, wann immer git fetch --prune ausgeführt wird, ohne jede Ausführung von git fetch ohne --prune zu einem Fehler zu machen.

Das Bereinigen von Tags mit --prune-tags funktioniert auch beim Abrufen einer URL anstelle eines benannten Remotes. Diese Befehle bereinigen alle Tags, die nicht auf origin gefunden werden:

$ git fetch origin --prune --prune-tags
$ git fetch origin --prune 'refs/tags/*:refs/tags/*'
$ git fetch <url-of-origin> --prune --prune-tags
$ git fetch <url-of-origin> --prune 'refs/tags/*:refs/tags/*'

AUSGABE

Die Ausgabe von "git fetch" hängt von der verwendeten Transportmethode ab; dieser Abschnitt beschreibt die Ausgabe beim Abrufen über das Git-Protokoll (lokal oder über ssh) und das Smart HTTP-Protokoll.

Der Status des Fetches wird tabellarisch ausgegeben, wobei jede Zeile den Status eines einzelnen Refs darstellt. Jede Zeile hat das Format:

 <flag> <summary> <from> -> <to> [<reason>]

Bei Verwendung von --porcelain ist das Ausgabeformat maschinenlesbar. Im Gegensatz zu den für Menschen lesbaren Ausgabeformaten wird hier also auf die Standardausgabe und nicht auf die Standardfehlerausgabe geschrieben. Jede Zeile hat das Format:

<flag> <old-object-id> <new-object-id> <local-reference>

Der Status von auf aktuellem Stand befindlichen Refs wird nur angezeigt, wenn die Option --verbose verwendet wird.

Im kompakten Ausgabemodus, spezifiziert durch die Konfigurationsvariable fetch.output, wird, wenn entweder der gesamte <from> oder <to> im anderen String gefunden wird, dieser mit * im anderen String ersetzt. Zum Beispiel wird master -> origin/master zu master -> origin/*.

flag

Ein einzelnes Zeichen, das den Status des Refs angibt.

(Leerzeichen)

für einen erfolgreich geholten Fast-Forward;

+

für ein erfolgreiches erzwungenes Update;

-

für ein erfolgreich bereinigtes Ref;

t

für ein erfolgreiches Tag-Update;

*

für ein erfolgreich geholtes neues Ref;

!

für ein Ref, das abgelehnt wurde oder dessen Update fehlgeschlagen ist; und

=

für ein Ref, das auf dem neuesten Stand war und nicht geholt werden musste.

zusammenfassung

Für ein erfolgreich geholtes Ref zeigt die Zusammenfassung die alten und neuen Werte des Refs in einem Format an, das als Argument für git log geeignet ist (dies ist in den meisten Fällen <old>..<new> und <old>...<new> für erzwungene Nicht-Fast-Forward-Updates).

von

Der Name des Remote-Refs, von dem geholt wird, abzüglich seines Präfixes refs/<type>/. Im Falle einer Löschung ist der Name des Remote-Refs "(none)".

zu

Der Name des lokalen Refs, das aktualisiert wird, abzüglich seines Präfixes refs/<type>/.

Grund

Eine für Menschen lesbare Erklärung. Im Falle von erfolgreich geholten Refs ist keine Erklärung erforderlich. Bei einem fehlgeschlagenen Ref wird der Grund für das Scheitern beschrieben.

BEISPIELE

  • Aktualisieren der Remote-Tracking-Branches

    $ git fetch origin

    Der obige Befehl kopiert alle Branches aus dem Remote-Namespace refs/heads/ und speichert sie im lokalen Namespace refs/remotes/origin/, es sei denn, die Option remote.<repository>.fetch wird verwendet, um eine nicht standardmäßige Refspec anzugeben.

  • Verwenden von Refspecs explizit

    $ git fetch origin +seen:seen maint:tmp

    Dies aktualisiert (oder erstellt, falls erforderlich) die Branches seen und tmp im lokalen Repository, indem von den Branches (jeweils) seen und maint aus dem Remote-Repository geholt wird.

    Der Branch seen wird auch dann aktualisiert, wenn er kein Fast-Forward ist, da er mit einem Pluszeichen (+) versehen ist; tmp wird dies nicht tun.

  • Ein Blick auf den Branch eines Remotes werfen, ohne das Remote in Ihrem lokalen Repository zu konfigurieren

    $ git fetch git://git.kernel.org/pub/scm/git/git.git maint
$ git log FETCH_HEAD

    Der erste Befehl holt den Branch maint aus dem Repository unter git://git.kernel.org/pub/scm/git/git.git und der zweite Befehl verwendet FETCH_HEAD, um den Branch mit git-log[1] zu untersuchen. Die geholten Objekte werden schließlich durch Git's integrierte Hausmeisterei entfernt (siehe git-gc[1]).

SICHERHEIT

Die Fetch- und Push-Protokolle sind nicht darauf ausgelegt, zu verhindern, dass eine Seite Daten von einem anderen Repository stiehlt, die nicht zum Teilen bestimmt waren. Wenn Sie private Daten haben, die Sie vor einem böswilligen Peer schützen müssen, ist Ihre beste Option, sie in einem anderen Repository zu speichern. Dies gilt sowohl für Clients als auch für Server. Insbesondere Namensräume auf einem Server sind für die Lesezugriffskontrolle nicht effektiv; Sie sollten einem Namensraum nur Lesezugriff gewähren, wenn Sie einem Client vertrauen würden, der Lesezugriff auf das gesamte Repository hat.

Die bekannten Angriffsvektoren sind wie folgt:

  1. Das Opfer sendet "have"-Zeilen, die die IDs von Objekten ankündigen, die es besitzt und die nicht explizit zum Teilen bestimmt sind, aber zur Optimierung der Übertragung verwendet werden können, wenn der Peer sie ebenfalls hat. Der Angreifer wählt ein Objekt-ID X zum Stehlen aus und sendet eine Ref auf X, muss aber nicht den Inhalt von X senden, da das Opfer es bereits hat. Nun glaubt das Opfer, dass der Angreifer X hat, und es sendet den Inhalt von X später zurück an den Angreifer. (Dieser Angriff ist für einen Client am einfachsten auf einen Server durchzuführen, indem eine Ref auf X in dem Namensraum erstellt wird, auf den der Client Zugriff hat, und diese dann geholt wird. Der wahrscheinlichste Weg für einen Server, dies auf einem Client durchzuführen, ist, X in einen öffentlichen Branch zu "mergen" und zu hoffen, dass der Benutzer zusätzliche Arbeit an diesem Branch leistet und ihn an den Server zurückpusht, ohne den Merge zu bemerken.)

  2. Wie in #1 wählt der Angreifer eine Objekt-ID X zum Stehlen aus. Das Opfer sendet ein Objekt Y, das der Angreifer bereits hat, und der Angreifer behauptet fälschlicherweise, X und nicht Y zu haben, so dass das Opfer Y als Delta gegen X sendet. Das Delta enthüllt dem Angreifer Regionen von X, die Y ähnlich sind.

KONFIGURATION

Alles unterhalb dieser Zeile in diesem Abschnitt wird selektiv aus der git-config[1]-Dokumentation übernommen. Der Inhalt ist derselbe wie dort zu finden.

fetch.recurseSubmodules

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. Das Setzen auf einen booleschen Wert ändert das Verhalten von fetch und pull, so dass bei true bedingungslos in Submodule rekursiert wird oder bei false überhaupt nicht. Wenn auf *on-demand* gesetzt, holt fetch und pull nur dann rekursiv in ein befülltes Submodul, wenn sein Superprojekt einen Commit abruft, der die Referenz des Submoduls aktualisiert. Standardmäßig *on-demand*, oder auf den Wert von *submodule.recurse*, wenn gesetzt.

fetch.fsckObjects

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

fetch.fsck.<msg-id>

Funktioniert wie fsck.<msg-id>, wird aber von git-fetch-pack[1] anstelle von git-fsck[1] verwendet. Siehe die Dokumentation zu fsck.<msg-id> für Details.

fetch.fsck.skipList

Funktioniert wie fsck.skipList, wird aber von git-fetch-pack[1] anstelle von git-fsck[1] verwendet. Siehe die Dokumentation zu fsck.skipList für Details.

fetch.unpackLimit

Wenn die Anzahl der über die native Git-Übertragung geholten Objekte unter diesem Limit liegt, werden die Objekte in lose Objektdateien entpackt. Wenn jedoch 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.

fetch.prune

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

fetch.pruneTags

Wenn true, verhält sich fetch automatisch so, als ob die Refspec refs/tags/*:refs/tags/* beim Pruning übergeben wurde, falls nicht bereits gesetzt. Dies ermöglicht es, sowohl diese Option als auch fetch.prune zu setzen, um eine 1:1-Zuordnung zu Upstream-Refs beizubehalten. Siehe auch remote.<name>.pruneTags und den Abschnitt PRUNING von git-fetch[1].

fetch.all

Wenn true, versucht fetch, alle verfügbaren Remotes zu aktualisieren. Dieses Verhalten kann durch Übergabe von --no-all oder durch explizite Angabe eines oder mehrerer Remotes zum Holen überschrieben werden. Standardmäßig false.

fetch.output

Steuert, wie der Status der Ref-Aktualisierung gedruckt wird. Gültige Werte sind full und compact. Standardwert ist full. Siehe den Abschnitt OUTPUT in git-fetch[1] für Details.

fetch.negotiationAlgorithm

Steuert, wie Informationen über die Commits im lokalen Repository gesendet werden, wenn die Inhalte der vom Server zu sendenden Packdatei ausgehandelt werden. Setzen Sie auf "consecutive", um einen Algorithmus zu verwenden, der aufeinanderfolgende Commits prüft. Setzen Sie auf "skipping", um einen Algorithmus zu verwenden, der Commits überspringt, um schneller zu konvergieren, aber möglicherweise zu einem größeren als notwendigen Packfile führt; oder setzen Sie auf "noop", um überhaupt keine Informationen zu senden, was mit ziemlicher Sicherheit zu einem größeren als notwendigen Packfile führt, aber den Verhandlungsschritt überspringt. Setzen Sie auf "default", um zuvor vorgenommene Einstellungen zu überschreiben und das Standardverhalten zu verwenden. Der Standard ist normalerweise "consecutive", aber wenn feature.experimental true ist, dann ist der Standard "skipping". Unbekannte Werte führen dazu, dass *git fetch* einen Fehler ausgibt.

Siehe auch die Optionen --negotiate-only und --negotiation-tip von git-fetch[1].

fetch.showForcedUpdates

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

fetch.parallel

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).

Ein Wert von 0 gibt einen vernünftigen Standardwert an. Wenn nicht gesetzt, ist der Standardwert 1.

Für Submodule kann diese Einstellung mit der Konfigurationseinstellung submodule.fetchJobs überschrieben werden.

fetch.writeCommitGraph

Setzen Sie auf true, um nach jedem git fetch-Befehl, der eine Packdatei von einem Remote herunterlädt, einen Commit-Graph zu schreiben. Mit der Option --split erstellen die meisten Ausführungen eine sehr kleine Commit-Graph-Datei über den vorhandenen Commit-Graph-Dateien. Gelegentlich werden diese Dateien zusammengeführt und der Schreibvorgang kann länger dauern. Ein aktualisierter Commit-Graph hilft bei der Performance vieler Git-Befehle, einschließlich git merge-base, git push -f und git log --graph. Standardmäßig false.

fetch.bundleURI

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

Wenn Sie diesen Wert ändern und Ihr Repository einen fetch.bundleCreationToken-Wert hat, entfernen Sie diesen fetch.bundleCreationToken-Wert, bevor Sie vom neuen Bundle-URI holen.

fetch.bundleCreationToken

Bei Verwendung von fetch.bundleURI zum inkrementellen Holen aus einer Bundle-Liste, die die "creationToken"-Heuristik verwendet, speichert dieser Konfigurationswert den maximalen creationToken-Wert der heruntergeladenen Bundles. Dieser Wert wird verwendet, um zukünftige Downloads von Bundles zu verhindern, wenn der angezeigte creationToken nicht streng größer als dieser Wert ist.

Die Creation-Token-Werte werden vom Anbieter ausgewählt, der die spezifische Bundle-URI bereitstellt. Wenn Sie die URI unter fetch.bundleURI ändern, stellen Sie sicher, dass Sie den Wert für fetch.bundleCreationToken entfernen, bevor Sie holen.

BUGS

Die Verwendung von --recurse-submodules kann nur neue Commits in Submodulen holen, die lokal vorhanden sind, z. B. in $GIT_DIR/modules/. Wenn der Upstream ein neues Submodul hinzufügt, kann dieses Submodul nicht geholt werden, bis es geklont wurde, z. B. mit git submodule update. Dies wird voraussichtlich in einer zukünftigen Git-Version behoben.

SIEHE AUCH

git-pull[1]

GIT

Teil der git[1] Suite