Schreibt in Paare von Dateien (.pack und .idx), wobei <basis-name> zur Bestimmung des Namens der erstellten Datei verwendet wird. Wenn diese Option verwendet wird, werden die beiden Dateien in einem Paar in den Dateien <basis-name>-<SHA-1>.{pack,idx} geschrieben. <SHA-1> ist ein Hash, der auf dem Pack-Inhalt basiert und auf die Standardausgabe des Befehls geschrieben wird.

Schreibt den Inhalt des Packs (was in die .pack-Datei geschrieben worden wäre) auf die Standardausgabe.

Liest die Revisionsargumente von der Standardeingabe anstelle einzelner Objekt-IDs. Die Revisionsargumente werden genauso verarbeitet, wie git rev-list mit dem Flag --objects seine commit-Argumente verwendet, um die Liste der von ihm ausgegebenen Objekte zu erstellen. Die Objekte auf der resultierenden Liste werden gepackt. Neben Revisions, werden auch --not oder --shallow <SHA-1>-Zeilen akzeptiert.

Dies impliziert --revs. Beim Verarbeiten der von der Standardeingabe gelesenen Liste von Revisionsargumenten werden nur die Objekte gepackt, die noch nicht gepackt sind.

Dies impliziert --revs. Zusätzlich zur Liste der von der Standardeingabe gelesenen Revisionsargumente wird so getan, als ob alle Refs unter refs/ zur Aufnahme angegeben wären.

Schließt nicht angeforderte annotierte Tags ein, wenn das von ihnen referenzierte Objekt im resultierenden Packfile enthalten war. Dies kann nützlich sein, um neue Tags an native Git-Clients zu senden.

Liest die Basisnamen von Packfiles (z.B. pack-1234abcd.pack) von der Standardeingabe anstelle von Objekt-IDs oder Revisionsargumenten. Das resultierende Pack enthält alle Objekte, die in den enthaltenen Packs aufgeführt sind (die nicht mit ^ beginnen), und schließt alle Objekte aus, die in den ausgeschlossenen Packs aufgeführt sind (die mit ^ beginnen).

Packt nicht erreichbare Objekte in ein separates "Cruft"-Pack, das durch die Existenz einer Datei .mtimes gekennzeichnet ist. Wird typischerweise von git repack --cruft verwendet. Aufrufer stellen eine Liste von Pack-Namen bereit und geben an, welche Packs im Repository verbleiben und welche gelöscht werden (angezeigt durch das Präfix -). Der Inhalt des Cruft-Packs sind alle Objekte, die nicht in den überlebenden Packs enthalten sind, die nicht die Gnadenfrist überschritten haben (siehe --cruft-expiration unten), oder die die Gnadenfrist überschritten haben, aber von einem anderen Objekt erreichbar sind, das dies nicht hat.

Wenn angegeben, werden Objekte aus dem Cruft-Pack eliminiert, wenn sie eine mtime haben, die älter ist als <approxidate>. Wenn nicht angegeben (und --cruft gegeben ist), werden keine Objekte eliminiert.

Diese beiden Optionen beeinflussen, wie die im Pack enthaltenen Objekte mit Delta-Kompression gespeichert werden. Die Objekte werden zuerst intern nach Typ, Größe und optional nach Namen sortiert und mit den anderen Objekten innerhalb von --window verglichen, um zu sehen, ob die Verwendung von Delta-Kompression Platz spart. --depth begrenzt die maximale Delta-Tiefe. Wenn sie zu tief eingestellt wird, beeinträchtigt dies die Leistung auf der Entpackerseite, da Delta-Daten so oft angewendet werden müssen, um zum benötigten Objekt zu gelangen.

Diese Option bietet eine zusätzliche Grenze über --window hinaus; die Fenstergröße wird dynamisch reduziert, sodass sie nicht mehr als <n> Bytes im Speicher belegt. Dies ist nützlich in Repositories mit einer Mischung aus großen und kleinen Objekten, um nicht mit einem großen Fenster den Speicher zu erschöpfen, aber dennoch die Vorteile eines großen Fensters für die kleineren Objekte nutzen zu können. Die Größe kann mit "k", "m" oder "g" suffigiert werden. --window-memory=0 macht die Speichernutzung unbegrenzt. Der Standardwert wird aus der Konfigurationsvariable pack.windowMemory übernommen.

In ungewöhnlichen Szenarien können Sie möglicherweise keine Dateien erstellen, die größer als eine bestimmte Größe auf Ihrem Dateisystem sind. Diese Option kann verwendet werden, um dem Befehl mitzuteilen, die Ausgabepackdatei in mehrere unabhängige Packdateien aufzuteilen, die jeweils nicht größer als die angegebene Größe sind. Die Größe kann mit "k", "m" oder "g" suffigiert werden. Die minimal zulässige Größe ist auf 1 MiB begrenzt. Der Standardwert ist unbegrenzt, es sei denn, die Konfigurationsvariable pack.packSizeLimit ist gesetzt. Beachten Sie, dass diese Option zu einem größeren und langsameren Repository führen kann; siehe die Diskussion in pack.packSizeLimit.

Dieses Flag bewirkt, dass ein Objekt, das sich bereits in einem lokalen Pack befindet und eine .keep-Datei hat, ignoriert wird, auch wenn es ansonsten gepackt worden wäre.

Dieses Flag bewirkt, dass ein Objekt, das sich bereits in dem angegebenen Pack befindet, ignoriert wird, auch wenn es ansonsten gepackt worden wäre. <pack-name> ist der Packdateiname ohne führendes Verzeichnis (z.B. pack-123.pack). Die Option kann mehrfach angegeben werden, um mehrere Packs zu behalten.

Dieses Flag bewirkt, dass ein Objekt, das sich bereits in einem Pack befindet, ignoriert wird, auch wenn es ansonsten gepackt worden wäre.

Dieses Flag bewirkt, dass ein Objekt, das aus einem alternativen Objektspeicher geliehen wurde, ignoriert wird, auch wenn es ansonsten gepackt worden wäre.

Erstellt nur dann ein gepacktes Archiv, wenn es mindestens ein Objekt enthält.

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.

Wenn --stdout angegeben ist, wird während der Objektzählung und der Komprimierungsphasen ein Fortschrittsbericht angezeigt, aber während der Ausgabephase unterdrückt. Der Grund dafür ist, dass in einigen Fällen der Ausgabestrom direkt mit einem anderen Befehl verknüpft ist, der möglicherweise einen eigenen Fortschrittsstatus anzeigen möchte, während er eingehende Packdaten verarbeitet. Dieses Flag ist wie --progress, außer dass es auch für die Ausgabephase einen Fortschrittsbericht erzwingt, auch wenn --stdout verwendet wird.

Dies wird verwendet, um --all-progress zu implizieren, wann immer die Fortschrittsanzeige aktiviert ist. Im Gegensatz zu --all-progress erzwingt dieses Flag selbst keine Fortschrittsanzeige.

Dieses Flag sorgt dafür, dass der Befehl seinen Fortschritt nicht auf dem Standardfehlerstrom meldet.

Beim Erstellen eines gepackten Archivs in einem Repository mit vorhandenen Packs wiederverwendet der Befehl bestehende Deltas. Dies führt manchmal zu einem etwas suboptimalen Pack. Dieses Flag weist den Befehl an, bestehende Deltas nicht wiederzuverwenden, sondern sie von Grund auf neu zu berechnen.

Dieses Flag weist den Befehl an, vorhandene Objektdaten überhaupt nicht wiederzuverwenden, einschließlich nicht-deltifizierter Objekte, und zwingt zur Neuberechnung von allem. Dies impliziert --no-reuse-delta. Nur im obskuren Fall nützlich, wenn eine vollständige Durchsetzung eines anderen Kompressionsgrads auf den gepackten Daten gewünscht wird.

Gibt die Komprimierungsstufe für neu komprimierte Daten im generierten Pack an. Wenn nicht angegeben, wird die Komprimierungsstufe des Packs zuerst durch pack.compression, dann durch core.compression bestimmt und standardmäßig auf -1 (die zlib-Standardeinstellung) gesetzt, wenn keines davon gesetzt ist. Fügen Sie --no-reuse-object hinzu, wenn Sie eine einheitliche Komprimierungsstufe für alle Daten erzwingen möchten, unabhängig von der Quelle.

Schaltet den "sparse"-Algorithmus zur Bestimmung der im Pack zu enthaltenen Objekte um, wenn er mit der Option "--revs" kombiniert wird. Dieser Algorithmus durchläuft nur Bäume, die in Pfaden vorkommen, die neue Objekte einführen. Dies kann erhebliche Leistungsvorteile bringen, wenn ein Pack zur Übermittlung einer kleinen Änderung berechnet wird. Es ist jedoch möglich, dass zusätzliche Objekte in die Packdatei aufgenommen werden, wenn die enthaltenen Commits bestimmte Arten von direkten Umbenennungen enthalten. Wenn diese Option nicht enthalten ist, wird standardmäßig der Wert von pack.useSparse verwendet, der true ist, sofern nicht anders angegeben.

Erstellt ein "dünnes" Pack, indem gemeinsame Objekte zwischen einem Sender und einem Empfänger weggelassen werden, um die Netzwerkübertragung zu reduzieren. Diese Option ist nur in Verbindung mit --stdout sinnvoll.

Optimiert ein Pack, das einem Client mit einem flachen Repository bereitgestellt werden soll. Diese Option kann in Kombination mit --thin zu einem kleineren Pack führen, jedoch auf Kosten der Geschwindigkeit.

Ein gepacktes Archiv kann das Basisobjekt eines Deltas entweder als 20-Byte-Objekt-ID oder als Offset im Stream ausdrücken, aber alte Git-Versionen verstehen letzteres nicht. Standardmäßig verwendet git pack-objects nur das erstere Format für bessere Kompatibilität. Diese Option ermöglicht es dem Befehl, das letztere Format für Kompaktheit zu verwenden. Abhängig von der durchschnittlichen Delta-Kettenlänge schrumpft diese Option typischerweise die resultierende Packdatei um 3-5 Prozent.

Gibt die Anzahl der Threads an, die beim Suchen nach den besten Delta-Übereinstimmungen erzeugt werden sollen. Dies erfordert, dass pack-objects mit pthreads kompiliert wurde, andernfalls wird diese Option mit einer Warnung ignoriert. Dies soll die Packzeit auf Mehrprozessormaschinen reduzieren. Der benötigte Speicher für das Delta-Suchfenster wird jedoch mit der Anzahl der Threads multipliziert. Die Angabe von 0 bewirkt, dass Git die Anzahl der CPUs automatisch erkennt und die Anzahl der Threads entsprechend einstellt.

Dies ist nur für die Testsuite vorgesehen. Es ermöglicht das Erzwingen der Version für den generierten Pack-Index und das Erzwingen von 64-Bit-Indexeinträgen für Objekte oberhalb des angegebenen Offsets.

Mit dieser Option werden Elternobjekte, die durch Grafting verborgen sind, trotzdem gepackt.

Lässt bestimmte Objekte (normalerweise Blobs) aus der resultierenden Packdatei weg. Siehe git-rev-list[1] für gültige <filter-spec>-Formen.

Deaktiviert jedes vorherige --filter=-Argument.

Eine Debugging-Option zur Unterstützung der zukünftigen Entwicklung von "partial clone". Diese Option gibt an, wie fehlende Objekte behandelt werden.

Schließt Objekte aus, von denen bekannt ist, dass sie sich im Promisor-Remote befinden. (Diese Option dient nur dazu, auf lokal erstellte Objekte zu operieren, damit wir bei einem Repack weiterhin zwischen lokal erstellten Objekten [ohne .promisor] und Objekten vom Promisor-Remote [mit .promisor] unterscheiden können.) Dies wird bei partiellen Klonen verwendet.

Objekte, die von den Refs in den mit --unpacked= angegebenen Packs nicht erreichbar sind, werden zusätzlich zu den erreichbaren Objekten, die sich nicht in mit *.keep-Dateien markierten Packs befinden, zum resultierenden Pack hinzugefügt. Dies impliziert --revs.

Packt nicht erreichbare lose Objekte (und entfernt ihre losen Gegenstücke). Dies impliziert --revs.

Behält nicht erreichbare Objekte in loser Form. Dies impliziert --revs.

Beschränkt Delta-Übereinstimmungen basierend auf "Inseln". Siehe DELTA ISLANDS unten.

Bei der Delta-Kompression gruppiert Git Objekte, die ähnlich sein könnten, basierend auf Heuristiken, die den Pfad zu diesem Objekt verwenden. Während die Gruppierung von Objekten nach einer exakten Pfadübereinstimmung für Pfade mit vielen Versionen gut ist, gibt es Vorteile bei der Suche nach Delta-Paaren über verschiedene vollständige Pfade hinweg. Git sammelt Objekte nach Typ und dann nach einem "Namen-Hash" des Pfades und dann nach Größe, in der Hoffnung, Objekte zu gruppieren, die gut zusammen komprimieren.

Führt die Komprimierung durch, indem zuerst Objekte nach Pfad organisiert werden, gefolgt von einem zweiten Durchgang, der wie gewohnt über Pfade hinweg komprimiert. Dies hat das Potenzial, die Delta-Kompression zu verbessern, insbesondere bei Dateinamen, die Kollisionen im standardmäßigen Namens-Hash-Algorithmus von Git verursachen.