English ▾ Themen ▾ Neueste Version ▾ git-fast-export zuletzt aktualisiert in 2.51.0

NAME

git-fast-export - Git-Datenexporteur

SYNOPSIS

git fast-export [<options>] | git fast-import

BESCHREIBUNG

Dieses Programm gibt die angegebenen Revisionen in einem Format aus, das geeignet ist, um es in git fast-import einzuspeisen.

Sie können es als menschenlesbaren Bundle-Ersatz verwenden (siehe git-bundle[1]) oder als Format, das bearbeitet werden kann, bevor es an git fast-import übergeben wird, um die Historie neu zu schreiben (eine Fähigkeit, die von Werkzeugen wie git filter-repo genutzt wird).

OPTIONEN

--progress=<n>

Fügt alle <n> Objekte progress-Anweisungen ein, die von git fast-import während des Imports angezeigt werden.

--signed-tags=(verbatim|warn-verbatim|warn-strip|strip|abort)

Gibt an, wie signierte Tags behandelt werden sollen. Da jede Transformation nach dem Export (oder während des Exports, z. B. durch den Ausschluss von Revisionen) die signierten Hashes ändern kann, können die Signaturen ungültig werden.

Wenn abort (Standard) angefordert wird, stirbt dieses Programm bei einem signierten Tag. Mit strip werden die Tags stillschweigend unsigniert, mit warn-strip werden sie unsigniert, aber eine Warnung wird angezeigt, mit verbatim werden sie stillschweigend exportiert und mit warn-verbatim (oder warn, einem veralteten Synonym) werden sie exportiert, aber Sie sehen eine Warnung. verbatim und warn-verbatim sollten nur verwendet werden, wenn Sie wissen, dass keine Transformation, die Tags oder Commits in ihrer Historie betrifft, von Ihnen oder von fast-export oder fast-import durchgeführt wird, oder wenn es Ihnen egal ist, dass der resultierende Tag eine ungültige Signatur hat.

--signed-commits=(verbatim|warn-verbatim|warn-strip|strip|abort)

Gibt an, wie signierte Commits behandelt werden sollen. Verhält sich genau wie --signed-tags, aber für Commits. Standard ist strip, was dem Verhalten früherer Versionen dieses Befehls ohne diese Option entspricht.

Beim Exportieren beginnt eine Signatur mit

gpgsig <git-hash-algo> <signature-format>

wobei <git-hash-algo> der Git-Objekthash ist, also entweder "sha1" oder "sha256", und <signature-format> der Signaturtyp ist, also "openpgp", "x509", "ssh" oder "unknown".

Zum Beispiel beginnt eine OpenPGP-Signatur auf einem SHA-1-Commit mit gpgsig sha1 openpgp, während eine SSH-Signatur auf einem SHA-256-Commit mit gpgsig sha256 ssh beginnt.

Während alle Signaturen eines Commits exportiert werden, kann ein Importeur wählen, nur einige davon zu akzeptieren. Zum Beispiel speichert git-fast-import[1] derzeit höchstens eine Signatur pro Git-Hash-Algorithmus in jedem Commit.

Hinweis
 Dies ist sehr experimentell und das Format des Datenstroms kann sich in Zukunft ohne Kompatibilitätsgarantien ändern.
--tag-of-filtered-object=(abort|drop|rewrite)

Gibt an, wie Tags behandelt werden sollen, deren getaggtes Objekt herausgefiltert wird. Da Revisionen und zu exportierende Dateien nach Pfad begrenzt werden können, können getaggte Objekte vollständig herausgefiltert werden.

Wenn abort (Standard) angefordert wird, stirbt dieses Programm bei einem solchen Tag. Mit drop werden solche Tags aus der Ausgabe weggelassen. Mit rewrite wird, wenn das getaggte Objekt ein Commit ist, der Tag neu geschrieben, um einen Vorgänger-Commit zu taggen (über Eltern-Rewriting; siehe git-rev-list[1]).

-M
-C

Führt eine Erkennung von Verschiebungen und/oder Kopien durch, wie auf der manuellen Seite git-diff[1] beschrieben, und verwendet diese, um Umbenennungs- und Kopierbefehle im Ausgabedump zu generieren.

Beachten Sie, dass frühere Versionen dieses Befehls keine Fehler meldeten und falsche Ergebnisse lieferten, wenn Sie diese Optionen angaben.

--export-marks=<Datei>

Schreibt die interne Marks-Tabelle bei Abschluss in die Datei <Datei>. Marks werden zeilenweise als :markid SHA-1 geschrieben. Nur Marks für Revisionen werden ausgegeben; Marks für Blobs werden ignoriert. Backends können diese Datei verwenden, um Imports nach Abschluss zu validieren oder die Marks-Tabelle über inkrementelle Läufe hinweg zu speichern. Da <Datei> erst am Ende geöffnet und abgeschnitten wird, kann derselbe Pfad sicher auch für --import-marks angegeben werden. Die Datei wird nicht geschrieben, wenn kein neues Objekt markiert/exportiert wurde.

--import-marks=<Datei>

Lädt die in <Datei> angegebenen Marks, bevor eine Eingabe verarbeitet wird. Die Eingabedatei muss existieren, lesbar sein und das gleiche Format wie von --export-marks erzeugt verwenden.

--mark-tags

Beschriftet neben Blobs und Commits auch Tags mit Mark-IDs. Dies ist nützlich in Verbindung mit --export-marks und --import-marks und auch nützlich (und notwendig) für den Export von verschachtelten Tags. Es schadet in anderen Fällen nicht und wäre Standard, aber viele fast-import Frontends sind nicht darauf vorbereitet, Tags mit Mark-Identifikatoren zu akzeptieren.

Bereits markierte Commits (oder Tags) werden nicht erneut exportiert. Wenn das Backend eine ähnliche --import-marks-Datei verwendet, ermöglicht dies einen inkrementellen bidirektionalen Export des Repositorys, indem die Marks über Läufe hinweg gleich bleiben.

--fake-missing-tagger

Einige alte Repositories haben Tags ohne Taggeber. Das fast-import-Protokoll war diesbezüglich recht streng und erlaubte dies nicht. Daher wird ein Taggeber gefälscht, um den Export per fast-import zu ermöglichen.

--use-done-feature

Beginnt den Stream mit einem feature done-Abschnitt und beendet ihn mit einem done-Befehl.

--no-data

Überspringt die Ausgabe von Blob-Objekten und verweist stattdessen auf Blobs über ihren ursprünglichen SHA-1-Hash. Dies ist nützlich, wenn die Verzeichnisstruktur oder die Historie eines Repositorys neu geschrieben wird, ohne die Inhalte einzelner Dateien zu berühren. Beachten Sie, dass der resultierende Stream nur von einem Repository verwendet werden kann, das die notwendigen Objekte bereits enthält.

--full-tree

Diese Option bewirkt, dass fast-export für jeden Commit eine "deleteall"-Direktive ausgibt, gefolgt von einer vollständigen Liste aller Dateien im Commit (im Gegensatz zur bloßen Auflistung der Dateien, die sich vom ersten Elternteil des Commits unterscheiden).

--anonymize

Anonymisiert den Inhalt des Repositorys, während die Struktur der Historie und des gespeicherten Baumes beibehalten wird. Siehe den Abschnitt über ANONYMISIERUNG unten.

--anonymize-map=<von>[:<zu>]

Konvertiert das Token <von> in <zu> in der anonymisierten Ausgabe. Wenn <zu> weggelassen wird, wird <von> auf sich selbst abgebildet (d. h., es wird nicht anonymisiert). Siehe den Abschnitt über ANONYMISIERUNG unten.

--reference-excluded-parents

Standardmäßig wird durch Ausführen eines Befehls wie git fast-export master~5..master der Commit master~5 nicht einbezogen und master~4 hat master~5 nicht mehr als Elternteil (obwohl sowohl das alte als auch das neue master~4 dieselben Dateien haben werden). Verwenden Sie --reference-excluded-parents, um stattdessen Commits im ausgeschlossenen Historienbereich durch ihre SHA1-Summe zu referenzieren. Beachten Sie, dass der resultierende Stream nur von einem Repository verwendet werden kann, das die notwendigen Eltern-Commits bereits enthält.

--show-original-ids

Fügt der Ausgabe für Commits und Blobs eine zusätzliche Direktive hinzu: original-oid <SHA1SUM>. Während solche Direktiven von Importern wie git-fast-import wahrscheinlich ignoriert werden, können sie für Zwischenfilter nützlich sein (z. B. zum Umschreiben von Commit-Nachrichten, die sich auf ältere Commits beziehen, oder zum Entfernen von Blobs nach ID).

--reencode=(yes|no|abort)

Gibt an, wie die Kopfzeile encoding in Commit-Objekten behandelt werden soll. Wenn abort (Standard) angefordert wird, stirbt dieses Programm bei einem solchen Commit-Objekt. Mit yes wird die Commit-Nachricht in UTF-8 neu kodiert. Mit no bleibt die ursprüngliche Kodierung erhalten.

--refspec

Wendet die angegebene Refspec auf jede exportierte Ref an. Mehrere davon können angegeben werden.

[<git-rev-list-args>…​]

Eine Liste von Argumenten, die für git rev-parse und git rev-list akzeptabel sind und die spezifischen Objekte und Referenzen angeben, die exportiert werden sollen. Zum Beispiel exportiert master~10..master die aktuelle master-Referenz zusammen mit allen Objekten, die seit ihrem 10. Vorfahrcocommit hinzugefügt wurden, und (sofern die Option --reference-excluded-parents nicht angegeben ist) allen Dateien, die master~9 und master~10 gemeinsam sind.

BEISPIELE

$ git fast-export --all | (cd /empty/repository && git fast-import)

Dies exportiert das gesamte Repository und importiert es in das bereits leere Repository. Abgesehen vom Neukodieren von Commits, die nicht in UTF-8 sind, wäre es ein Eins-zu-Eins-Spiegel.

$ git fast-export master~5..master |
	sed "s|refs/heads/master|refs/heads/other|" |
	git fast-import

Dies erstellt einen neuen Branch namens other aus master~5..master (d. h., wenn master eine lineare Historie hat, werden die letzten 5 Commits übernommen).

Beachten Sie, dass dies davon ausgeht, dass keiner der Blobs und Commit-Nachrichten, auf die sich dieser Revisionsbereich bezieht, den String refs/heads/master enthält.

ANONYMISIERUNG

Wenn die Option --anonymize angegeben wird, versucht git, alle identifizierenden Informationen aus dem Repository zu entfernen, während genügend der ursprünglichen Baum- und Historienmuster beibehalten werden, um einige Fehler zu reproduzieren. Das Ziel ist, dass ein Git-Fehler, der in einem privaten Repository gefunden wird, im anonymisierten Repository fortbesteht und letzteres mit Git-Entwicklern geteilt werden kann, um den Fehler zu beheben.

Mit dieser Option ersetzt git alle Refnamen, Pfade, Blob-Inhalte, Commit- und Tag-Nachrichten, Namen und E-Mail-Adressen in der Ausgabe durch anonymisierte Daten. Zwei Instanzen desselben Strings werden äquivalent ersetzt (z. B. werden zwei Commits mit demselben Autor im anonymisierten Autor in der Ausgabe gleich sein, aber keine Ähnlichkeit mit der ursprünglichen Autorzeichenkette aufweisen). Die Beziehungen zwischen Commits, Branches und Tags bleiben erhalten, ebenso die Commit-Zeitstempel (aber die Commit-Nachrichten und Refnamen ähneln den Originalen nicht). Die relative Zusammensetzung des Baumes bleibt erhalten (z. B. wenn Sie einen Root-Baum mit 10 Dateien und 3 Bäumen haben, wird dies auch in der Ausgabe der Fall sein), aber ihre Namen und die Inhalte der Dateien werden ersetzt.

Wenn Sie glauben, einen Git-Fehler gefunden zu haben, können Sie damit beginnen, einen anonymisierten Stream des gesamten Repositorys zu exportieren

$ git fast-export --anonymize --all >anon-stream

Bestätigen Sie dann, dass der Fehler in einem Repository fortbesteht, das aus diesem Stream erstellt wurde (viele Fehler werden dies nicht tun, da sie wirklich von den genauen Repository-Inhalten abhängen)

$ git init anon-repo
$ cd anon-repo
$ git fast-import <../anon-stream
$ ... test your bug ...

Wenn das anonymisierte Repository den Fehler zeigt, kann es sich lohnen, anon-stream zusammen mit einem regulären Fehlerbericht zu teilen. Beachten Sie, dass der anonymisierte Stream sehr gut komprimiert, daher wird das Gzippen empfohlen. Wenn Sie den Stream untersuchen möchten, um sicherzustellen, dass er keine privaten Daten enthält, können Sie ihn direkt durchsuchen, bevor Sie ihn senden. Möglicherweise möchten Sie auch versuchen

$ perl -pe 's/\d+/X/g' <anon-stream | sort -u | less

was alle eindeutigen Zeilen anzeigt (wobei Zahlen in "X" umgewandelt werden, um "Benutzer 0", "Benutzer 1" usw. zu "Benutzer X" zusammenzufassen). Dies erzeugt eine viel kleinere Ausgabe und es ist normalerweise einfach, schnell zu bestätigen, dass keine privaten Daten im Stream vorhanden sind.

Das Reproduzieren einiger Fehler kann das Referenzieren bestimmter Commits oder Pfade erfordern, was nach der Anonymisierung von Refnamen und Pfaden schwierig wird. Sie können verlangen, dass ein bestimmtes Token beibehalten oder auf einen neuen Wert abgebildet wird. Wenn Sie beispielsweise einen Fehler haben, der mit git rev-list sensitive -- secret.c reproduzierbar ist, können Sie Folgendes ausführen:

$ git fast-export --anonymize --all \
      --anonymize-map=sensitive:foo \
      --anonymize-map=secret.c:bar.c \
      >stream

Nach dem Importieren des Streams können Sie dann git rev-list foo -- bar.c im anonymisierten Repository ausführen.

Beachten Sie, dass Pfade und Refnamen an Schrägstrich-Grenzen in Token aufgeteilt werden. Der obige Befehl würde subdir/secret.c als etwas wie path123/bar.c anonymisieren; Sie könnten dann nach bar.c im anonymisierten Repository suchen, um den endgültigen Pfadnamen zu ermitteln.

Um die Referenzierung des endgültigen Pfadnamens zu vereinfachen, können Sie jede Pfadkomponente abbilden; wenn Sie also auch subdir in publicdir anonymisieren, wäre der endgültige Pfadname publicdir/bar.c.

EINSCHRÄNKUNGEN

Da git fast-import keine Bäume taggen kann, können Sie das linux.git-Repository nicht vollständig exportieren, da es einen Tag enthält, der auf einen Baum anstatt auf einen Commit verweist.

SIEHE AUCH

git-fast-import[1]

GIT

Teil der git[1] Suite