English ▾ Themen ▾ Neueste Version ▾ git-sparse-checkout zuletzt aktualisiert in 2.52.0

NAME

git-sparse-checkout – Reduzieren Sie Ihren Arbeitsbaum auf eine Teilmenge verfolgter Dateien

SYNOPSIS

git sparse-checkout (init | list | set | add | reapply | disable | check-rules | clean) [<options>]

BESCHREIBUNG

Dieser Befehl wird verwendet, um Sparse-Checkouts zu erstellen, die den Arbeitsbaum von der Anwesenheit aller verfolgten Dateien auf nur eine Teilmenge dieser Dateien ändern. Er kann auch wechseln, welche Teilmenge von Dateien vorhanden ist, oder rückgängig machen und zurückkehren, um alle verfolgten Dateien in der Arbeitskopie zu haben.

Die Teilmenge von Dateien wird durch Angabe einer Liste von Verzeichnissen im Kegelmodus (Standard) oder durch Angabe einer Liste von Mustern im Nicht-Kegelmodus ausgewählt.

Im Sparse-Checkout-Modus verhalten sich andere Git-Befehle etwas anders. Zum Beispiel werden beim Wechseln von Zweigen keine Pfade außerhalb der Sparse-Checkout-Verzeichnisse/Muster aktualisiert, und git commit -a zeichnet keine Pfade außerhalb der Sparse-Checkout-Verzeichnisse/Muster als gelöscht auf.

DIESER BEFEHL IST EXPERIMENTELL. SEIN VERHALTEN UND DAS VERHALTEN ANDERER BEFEHLE IM KONTEXT VON SPARSE-CHECKOUTS KÖNNEN SICH IN DER ZUKUNFT ÄNDERN.

BEFEHLE

list

Beschreiben Sie die Verzeichnisse oder Muster in der Sparse-Checkout-Datei.

set

Aktivieren Sie die notwendigen Sparse-Checkout-Konfigurationseinstellungen (core.sparseCheckout, core.sparseCheckoutCone und index.sparse), falls diese nicht bereits auf die gewünschten Werte gesetzt sind, füllen Sie die Sparse-Checkout-Datei mit der Liste der nach dem set-Unterbefehl folgenden Argumente und aktualisieren Sie das Arbeitsverzeichnis entsprechend.

Um sicherzustellen, dass die Anpassung der Sparse-Checkout-Einstellungen innerhalb eines Worktrees die Sparse-Checkout-Einstellungen in anderen Worktrees nicht verändert, aktualisiert der set-Unterbefehl die Repository-Konfiguration, um eine für Worktrees spezifische Konfiguration zu verwenden, falls diese noch nicht vorhanden ist. Die durch die Argumente an den set-Unterbefehl definierte Sparsity wird in der für Worktrees spezifischen Sparse-Checkout-Datei gespeichert. Weitere Details finden Sie in git-worktree[1] und in der Dokumentation von extensions.worktreeConfig in git-config[1].

Wenn die Option --stdin angegeben wird, werden die Verzeichnisse oder Muster als durch Zeilenumbrüche getrennte Liste aus der Standardeingabe gelesen, anstatt aus den Argumenten.

Standardmäßig wird die Eingabeliste als Liste von Verzeichnissen interpretiert, entsprechend der Ausgabe von git ls-tree -d --name-only. Dies beinhaltet die Interpretation von Pfadnamen, die mit einem doppelten Anführungszeichen (") beginnen, als C-Style-Anführungszeichen. Beachten Sie, dass alle Dateien unter den angegebenen Verzeichnissen (in beliebiger Tiefe) in den Sparse-Checkout aufgenommen werden, ebenso wie Dateien, die Geschwister des gegebenen Verzeichnisses oder eines seiner Vorfahren sind (weitere Details siehe KEGEL-MUSSERSATZ unten). Früher war dies nicht die Standardeinstellung, und --cone musste angegeben oder core.sparseCheckoutCone aktiviert werden.

Wenn --no-cone übergeben wird, wird die Eingabeliste als Liste von Mustern interpretiert. Dieser Modus hat eine Reihe von Nachteilen, einschließlich der Tatsache, dass er nicht mit einigen Optionen wie --sparse-index funktioniert. Wie im Abschnitt "Nicht-Kegel-Probleme" unten erklärt, empfehlen wir die Verwendung nicht.

Verwenden Sie die Option --[no-]sparse-index, um einen Sparse-Index zu verwenden (Standard ist die Nicht-Verwendung). Ein Sparse-Index reduziert die Größe des Index, um besser mit Ihrer Sparse-Checkout-Definition übereinzustimmen. Dies kann erhebliche Leistungsvorteile für Befehle wie git status oder git add haben. Dieses Feature ist noch experimentell. Einige Befehle könnten mit einem Sparse-Index langsamer sein, bis sie ordnungsgemäß mit dem Feature integriert sind.

WARNUNG: Die Verwendung eines Sparse-Index erfordert Änderungen am Index in einer Weise, die von externen Werkzeugen nicht vollständig verstanden wird. Wenn Sie Kompatibilitätsprobleme haben, führen Sie git sparse-checkout init --no-sparse-index aus, um Ihren Index neu zu schreiben und ihn nicht als Sparse zu kennzeichnen. Ältere Git-Versionen verstehen die Indexerweiterung für Sparse-Verzeichniseinträge nicht und können bei der Interaktion mit Ihrem Repository fehlschlagen, bis sie deaktiviert ist.

add

Aktualisieren Sie die Sparse-Checkout-Datei, um zusätzliche Verzeichnisse (im Kegelmodus) oder Muster (im Nicht-Kegelmodus) einzuschließen. Standardmäßig werden diese Verzeichnisse oder Muster aus den Befehlszeilenargumenten gelesen, können aber über die Option --stdin von stdin gelesen werden.

reapply

Wenden Sie die Sparse-Musterregeln erneut auf Pfade im Arbeitsbaum an. Befehle wie merge oder rebase können Pfade materialisieren, um ihre Arbeit zu erledigen (z. B. um Ihnen einen Konflikt zu zeigen), und andere Sparse-Checkout-Befehle können möglicherweise eine einzelne Datei nicht sparsifizieren (z. B. weil sie ungespeicherte Änderungen oder Konflikte hat). In solchen Fällen kann es sinnvoll sein, später git sparse-checkout reapply auszuführen, nachdem die betroffenen Pfade bereinigt wurden (z. B. Konflikte lösen, Änderungen rückgängig machen oder committen usw.).

Der Befehl reapply kann auch --[no-]cone und --[no-]sparse-index Flaggen mit der gleichen Bedeutung wie die Flaggen des Befehls set annehmen, um den verwendeten Sparsity-Modus zu ändern, ohne alle Sparsity-Pfade erneut angeben zu müssen.

clean

Entfernen Sie opportunistisch Dateien außerhalb der Sparse-Checkout-Definition. Dieser Befehl erfordert den Kegelmodus, um rekursive Verzeichnismatches zu verwenden, um zu bestimmen, welche Dateien entfernt werden sollen. Eine Datei wird zur Entfernung in Betracht gezogen, wenn sie sich in einem verfolgten Verzeichnis befindet, das außerhalb der Sparse-Checkout-Definition liegt.

Einige Sonderfälle, wie Merge-Konflikte oder geänderte Dateien außerhalb der Sparse-Checkout-Definition, könnten dazu führen, dass Dateien beibehalten werden, die sonst entfernt würden. Lösen Sie Konflikte, committen Sie Änderungen und verwenden Sie git sparse-checkout reapply in Verbindung mit git sparse-checkout clean, um diese Fälle zu lösen.

Dieser Befehl kann verwendet werden, um sicherzustellen, dass der Sparse-Index effizient arbeitet, obwohl er nicht erfordert, dass das Sparse-Index-Feature über die Konfiguration index.sparse=true aktiviert wird.

Um eine versehentliche Löschung von Worktree-Dateien zu verhindern, löscht der Unterbefehl clean keine Dateien ohne die Option -f oder --force, es sei denn, die Konfigurationsoption clean.requireForce ist auf false gesetzt.

Die Option --dry-run listet die Verzeichnisse auf, die entfernt würden, ohne sie zu löschen. Das Ausführen in diesem Modus kann hilfreich sein, um das Verhalten des clean-Befehls vorherzusagen oder um zu bestimmen, welche Arten von Dateien in den Sparse-Verzeichnissen verbleiben.

Die Option --verbose listet jede Datei in den Verzeichnissen auf, die für die Entfernung in Betracht gezogen werden. Diese Option ist hilfreich, um festzustellen, ob diese Dateien tatsächlich wichtig sind, oder um zu erklären, warum das Verzeichnis trotz des aktuellen Sparse-Checkouts noch vorhanden ist.

disable

Deaktivieren Sie die Konfigurationseinstellung core.sparseCheckout und stellen Sie den Arbeitsbaum wieder her, um alle Dateien einzuschließen.

init

Veralteter Befehl, der sich wie set ohne angegebene Pfade verhält. Könnte in Zukunft entfernt werden.

Historisch gesehen behandelte set nicht alle notwendigen Konfigurationseinstellungen, was bedeutete, dass sowohl init als auch set aufgerufen werden mussten. Das Aufrufen beider bedeutete, dass der init-Schritt zuerst fast alle verfolgten Dateien entfernte (und im Kegelmodus auch ignorierte Dateien), dann würde der set-Schritt viele der verfolgten Dateien (aber nicht ignorierte Dateien) wieder hinzufügen. Zusätzlich zu den verlorenen Dateien waren die Leistung und die Benutzeroberfläche dieser Kombination schlecht.

Darüber hinaus initialisierte init historisch gesehen die Sparse-Checkout-Datei nicht tatsächlich, wenn sie bereits existierte. Das bedeutete, dass es möglich war, zu einem Sparse-Checkout zurückzukehren, ohne sich daran zu erinnern, welche Pfade an einen nachfolgenden set- oder add-Befehl übergeben werden sollten. Die Optionen --cone und --sparse-index wurden jedoch über den disable-Befehl hinweg nicht gespeichert, sodass die einfache Wiederherstellung durch Aufrufen eines einfachen init an Nutzen verlor.

check-rules

Überprüfen Sie, ob Sparsity-Regeln mit einem oder mehreren Pfaden übereinstimmen.

Standardmäßig liest check-rules eine Liste von Pfaden aus stdin und gibt nur diejenigen aus, die mit den aktuellen Sparsity-Regeln übereinstimmen. Die Eingabe wird als ein Pfad pro Zeile erwartet und entspricht der Ausgabe von git ls-tree --name-only, wobei Pfadnamen, die mit einem doppelten Anführungszeichen (") beginnen, als C-Style-Anführungszeichen interpretiert werden.

Wenn der Befehl mit der Flagge --rules-file <file> aufgerufen wird, werden die Eingabedateien mit den Sparsity-Regeln abgeglichen, die in <file> gefunden werden, anstatt mit den aktuellen. Die Regeln in den Dateien werden in derselben Form erwartet, wie sie von git sparse-checkout set --stdin akzeptiert werden (insbesondere müssen sie durch Zeilenumbrüche getrennt sein).

Standardmäßig werden die Regeln, die an die Option --rules-file übergeben werden, als Kegelmodus-Verzeichnisse interpretiert. Um Nicht-Kegelmodus-Muster mit --rules-file zu übergeben, kombinieren Sie die Option mit der Option --no-cone.

Wenn der Befehl mit der Flagge -z aufgerufen wird, ist das Format der auf stdin übergebenen Pfade sowie die Ausgabepfade nullterminiert und nicht zitiert. Beachten Sie, dass dies nicht für das Format der mit der Option --rules-file übergebenen Regeln gilt.

BEISPIELE

git sparse-checkout set MY/DIR1 SUB/DIR2

Wechseln Sie zu einem Sparse-Checkout, bei dem alle Dateien (in beliebiger Tiefe) unter MY/DIR1/ und SUB/DIR2/ in der Arbeitskopie vorhanden sind (plus alle Dateien direkt unter MY/ und SUB/ sowie im obersten Verzeichnis). Wenn Sie sich bereits in einem Sparse-Checkout befinden, ändern Sie die vorhandenen Dateien in der Arbeitskopie auf diese neue Auswahl. Beachten Sie, dass dieser Befehl auch alle ignorierten Dateien in Verzeichnissen löscht, die weder verfolgte noch nicht ignorierte, nicht verfolgte Dateien enthalten.

git sparse-checkout disable

Füllen Sie die Arbeitskopie mit allen Dateien neu auf und deaktivieren Sie Sparse-Checkouts.

git sparse-checkout add SOME/DIR/ECTORY

Fügen Sie alle Dateien unter SOME/DIR/ECTORY/ (in beliebiger Tiefe) zum Sparse-Checkout hinzu, sowie alle Dateien direkt unter SOME/DIR/ und direkt unter SOME/. Sie müssen sich bereits in einem Sparse-Checkout befinden, bevor Sie diesen Befehl verwenden.

git sparse-checkout reapply

Es ist möglich, dass Befehle den Arbeitsbaum so aktualisieren, dass die ausgewählten Sparsity-Verzeichnisse nicht berücksichtigt werden. Dies kann von externen Werkzeugen stammen, die Dateien schreiben, oder sogar Git-Befehle beeinflussen, entweder aufgrund von Sonderfällen (wie z. B. Konflikten beim Mergen/Rebasen) oder weil einige Befehle Sparse-Checkouts nicht vollständig unterstützten (z. B. hatte das alte recursive Merge-Backend nur eingeschränkte Unterstützung). Dieser Befehl wendet die bestehenden Sparse-Verzeichnis-Spezifikationen erneut an, um den Arbeitsbaum anzupassen.

INTERNALS — SPARSE CHECKOUT

"Sparse checkout" ermöglicht das spärliche Befüllen des Arbeitsbaums. Es verwendet das skip-worktree-Bit (siehe git-update-index[1]), um Git mitzuteilen, ob eine Datei im Arbeitsbaum sehenswert ist. Wenn das skip-worktree-Bit gesetzt ist und die Datei im Arbeitsbaum nicht vorhanden ist, wird ihre Abwesenheit ignoriert. Git wird das Befüllen der Inhalte dieser Dateien vermeiden, was einen Sparse-Checkout hilfreich macht, wenn man in einem Repository mit vielen Dateien arbeitet, aber nur wenige für den aktuellen Benutzer wichtig sind.

Die Datei $GIT_DIR/info/sparse-checkout wird verwendet, um die skip-worktree-Referenz-Bitmap zu definieren. Wenn Git den Arbeitsbaum aktualisiert, aktualisiert es die skip-worktree-Bits im Index basierend auf dieser Datei. Die Dateien, die mit den Mustern in der Datei übereinstimmen, erscheinen im Arbeitsbaum, die restlichen nicht.

INTERNALS — NICHT-KEGEL-PROBLEME

Die Datei $GIT_DIR/info/sparse-checkout, die von den Unterbefehlen set und add gefüllt wird, ist als eine Reihe von Mustern (eines pro Zeile) definiert, die die gleiche Syntax wie .gitignore-Dateien verwenden. Im Kegelmodus sind diese Muster auf das Übereinstimmen von Verzeichnissen beschränkt (und Benutzer müssen nur Verzeichnisnamen angeben oder sehen), während im Nicht-Kegelmodus jedes Gitignore-ähnliche Muster zulässig ist. Die Verwendung der vollständigen Gitignore-ähnlichen Muster im Nicht-Kegelmodus hat eine Reihe von Nachteilen

  • Grundsätzlich erfordern verschiedene Arbeitsbaum-aktualisierende Prozesse (pull, merge, rebase, switch, reset, checkout usw.) O(N*M) Mustervergleiche, wobei N die Anzahl der Muster und M die Anzahl der Pfade im Index ist. Dies skaliert schlecht.

  • Die Vermeidung des Skalierungsproblems muss durch die Begrenzung der Anzahl von Mustern durch Angabe eines führenden Verzeichnisnamens oder Globs erfolgen.

  • Die Übergabe von Globs auf der Kommandozeile ist fehleranfällig, da Benutzer vergessen können, den Glob zu zitieren, was dazu führt, dass die Shell ihn in alle übereinstimmenden Dateien erweitert und sie einzeln an sparse-checkout set/add übergibt. Während dies auch ein Problem bei z. B. "git grep — *.c" sein könnte, treten Fehler bei grep/log/status in der sofortigen Ausgabe auf. Bei sparse-checkout wird der Fehler zum Zeitpunkt der Ausführung des sparse-checkout-Befehls aufgezeichnet und ist möglicherweise erst problematisch, wenn der Benutzer später den Zweig wechselt oder rebased oder merged, wodurch eine Verzögerung zwischen dem Fehler des Benutzers und der Möglichkeit, ihn zu erkennen/bemerken, entsteht.

  • Im Zusammenhang mit dem vorherigen Punkt hat sparse-checkout einen add-Unterbefehl, aber keinen remove-Unterbefehl. Selbst wenn ein remove-Unterbefehl hinzugefügt würde, birgt das Rückgängigmachen eines versehentlich nicht zitierten Globs das Risiko, "zu viel zu entfernen", da er Einträge entfernen könnte, die vor dem versehentlichen Hinzufügen enthalten waren.

  • Der Nicht-Kegelmodus verwendet Gitignore-ähnliche Muster, um auszuwählen, was **einzuschließen** ist (mit Ausnahme negierter Muster), während .gitignore-Dateien Gitignore-ähnliche Muster verwenden, um auszuwählen, was **auszuschließen** ist (mit Ausnahme negierter Muster). Die Dokumentation zu Gitignore-ähnlichen Mustern spricht normalerweise nicht vom Abgleichen oder Nicht-Abgleichen, sondern davon, was der Benutzer "ausschließen" möchte. Dies kann zu Verwirrung bei Benutzern führen, die lernen möchten, wie sie Sparse-Checkout-Muster angeben, um ihr gewünschtes Verhalten zu erzielen.

  • Jeder andere Git-Unterbefehl, der eine Art von "spezieller Pfadmusterübereinstimmung" bereitstellen möchte, verwendet Pfadspezifikationen, aber der Nicht-Kegelmodus für Sparse-Checkout verwendet Gitignore-Muster, was inkonsistent erscheint.

  • Es gibt Grenzfälle, bei denen das "richtige" Verhalten unklar ist. Zwei Beispiele

    Erstens, zwei Benutzer befinden sich in einem Unterverzeichnis, und der erste führt aus

    git sparse-checkout set '/toplevel-dir/*.c'

    während der zweite ausführt

    git sparse-checkout set relative-dir

    Sollten diese Argumente in übersetzt werden

    current/subdirectory/toplevel-dir/*.c

    und

    current/subdirectory/relative-dir

    bevor sie in die Sparse-Checkout-Datei eingefügt werden? Der Benutzer, der den ersten Befehl eingegeben hat, ist sich wahrscheinlich bewusst, dass Argumente für set/add Muster im Nicht-Kegelmodus sein sollen, und wäre wahrscheinlich nicht glücklich mit einer solchen Transliteration. Viele Gitignore-ähnliche Muster sind jedoch nur Pfade, was der Benutzer, der den zweiten Befehl eingegeben hat, gedacht haben mag, und er wäre verärgert, wenn sein Argument nicht transliteriert würde.

    Zweitens, was sollte Bash-Completion für set/add-Befehle für Nicht-Kegel-Benutzer abschließen? Wenn es Pfade vorschlägt, verschärft es das obige Problem? Wenn es Pfade vorschlägt, was ist, wenn der Benutzer eine Datei oder ein Verzeichnis hat, das mit entweder einem ! oder # beginnt oder ein *, \, ?, [ oder ] in seinem Namen hat? Und wenn es Pfade vorschlägt, wird es "/pro" zu "/proc" (im Root-Dateisystem) abschließen, anstatt zu "/progress.txt" im aktuellen Verzeichnis? (Beachten Sie, dass Benutzer im Nicht-Kegelmodus wahrscheinlich Pfade mit einem führenden / beginnen möchten, aus demselben Grund, warum .gitignore-Dateien oft einen haben.) Das Abschließen von Dateien oder Verzeichnissen könnte in all diesen Fällen unangenehme Überraschungen bereiten.

  • Die übermäßige Flexibilität machte andere Erweiterungen im Wesentlichen unpraktisch. --sparse-index ist im Nicht-Kegelmodus wahrscheinlich unmöglich; selbst wenn es irgendwie machbar wäre, wäre es viel mehr Arbeit gewesen, es zu implementieren, und es wäre möglicherweise praktisch zu langsam gewesen. Einige Ideen zur Kopplung von Teil-Klonen und Sparse-Checkouts sind auch nur mit einer eingeschränkteren Auswahl von Pfaden praktisch.

Aus all diesen Gründen ist der Nicht-Kegelmodus veraltet. Bitte wechseln Sie zur Verwendung des Kegelmodus.

INTERNALS — KEGEL-MODUS-HANDHABUNG

Der "Kegelmodus", der der Standard ist, ermöglicht die Angabe nur von Verzeichnissen, die eingeschlossen werden sollen. Für jedes angegebene Verzeichnis werden alle Pfade unterhalb dieses Verzeichnisses eingeschlossen, und alle Pfade direkt unter führenden Verzeichnissen (einschließlich des obersten Verzeichnisses) werden ebenfalls eingeschlossen. Wenn Sie also das Verzeichnis Documentation/technical/ angegeben haben, würde Ihr Sparse-Checkout Folgendes enthalten:

  • alle Dateien im obersten Verzeichnis

  • alle Dateien direkt unter Documentation/

  • alle Dateien in beliebiger Tiefe unter Documentation/technical/

Auch im Kegelmodus werden, selbst wenn keine Verzeichnisse angegeben sind, die Dateien im obersten Verzeichnis eingeschlossen.

Beim Ändern der Sparse-Checkout-Muster im Kegelmodus untersucht Git jedes verfolgte Verzeichnis, das sich nicht innerhalb des Sparse-Checkout-Kegels befindet, um zu sehen, ob es nicht verfolgte Dateien enthält. Wenn alle diese Dateien aufgrund von .gitignore-Mustern ignoriert werden, wird das Verzeichnis gelöscht. Wenn eine der nicht verfolgten Dateien in diesem Verzeichnis nicht ignoriert wird, werden innerhalb dieses Verzeichnisses keine Löschungen vorgenommen und eine Warnmeldung angezeigt. Wenn diese Dateien wichtig sind, setzen Sie Ihre Sparse-Checkout-Definition zurück, damit sie eingeschlossen werden, verwenden Sie git add und git commit, um sie zu speichern, und entfernen Sie dann alle verbleibenden Dateien manuell, um sicherzustellen, dass Git optimal funktionieren kann.

Siehe auch den Abschnitt "Internals — Cone Pattern Set", um zu erfahren, wie die Verzeichnisse im Hintergrund in eine Teilmenge des vollständigen Muster-Sets des Sparse-Checkouts umgewandelt werden.

INTERNALS — VOLLSTÄNDIGER MUSSERSATZ

Der vollständige Muster-Satz ermöglicht beliebige Mustervergleiche und komplizierte Ein-/Ausschlussregeln. Diese können zu O(N*M) Mustervergleichen bei der Aktualisierung des Index führen, wobei N die Anzahl der Muster und M die Anzahl der Pfade im Index ist. Um dieses Leistungsproblem zu bekämpfen, ist ein eingeschränkterer Muster-Satz zulässig, wenn core.sparseCheckoutCone aktiviert ist.

Die Sparse-Checkout-Datei verwendet die gleiche Syntax wie .gitignore-Dateien; siehe gitignore[5] für Details. Hier werden die Muster jedoch normalerweise verwendet, um auszuwählen, welche Dateien eingeschlossen werden sollen, anstatt welche Dateien ausgeschlossen werden sollen. (Es kann jedoch etwas verwirrend werden, da Gitignore-ähnliche Muster Negationen haben, die durch Muster definiert sind, die mit einem ! beginnen, sodass Sie auch Dateien auswählen können, die *nicht* eingeschlossen werden sollen.)

Zum Beispiel, um alles auszuwählen und dann die Datei unwanted zu entfernen (sodass jede Datei in Ihrem Arbeitsbaum erscheint, außer der Datei namens unwanted)

git sparse-checkout set --no-cone '/*' '!unwanted'

Diese Muster werden einfach wie sie sind in die $GIT_DIR/info/sparse-checkout eingefügt, sodass der Inhalt dieser Datei zu diesem Zeitpunkt lauten würde

/*
!unwanted

Siehe auch den Abschnitt "Sparse Checkout" in git-read-tree[1], um mehr über die Gitignore-ähnlichen Muster zu erfahren, die in Sparse-Checkouts verwendet werden.

INTERNALS — KEGEL-MUSSERSATZ

Im Kegelmodus werden nur Verzeichnisse akzeptiert, aber sie werden in die gleichen Gitignore-ähnlichen Muster übersetzt, die im vollständigen Muster-Satz verwendet werden. Wir bezeichnen die spezifischen Muster, die in diesen Modi verwendet werden, als von einem der beiden Typen

  1. Rekursiv: Alle Pfade innerhalb eines Verzeichnisses werden eingeschlossen.

  2. Eltern: Alle Dateien, die sich unmittelbar in einem Verzeichnis befinden, werden eingeschlossen.

Da der Kegelmodus immer Dateien im obersten Verzeichnis einschließt, wird beim Ausführen von git sparse-checkout set ohne angegebene Verzeichnisse das oberste Verzeichnis als Elternmuster hinzugefügt. Zu diesem Zeitpunkt enthält die Sparse-Checkout-Datei die folgenden Muster

/*
!/*/

Dies bedeutet "schließe alles direkt unterhalb des obersten Verzeichnisses ein, aber nichts in einer darunter liegenden Ebene."

Im Kegelmodus nimmt der Unterbefehl git sparse-checkout set eine Liste von Verzeichnissen entgegen. Der Befehl git sparse-checkout set A/B/C setzt das Verzeichnis A/B/C als rekursives Muster, die Verzeichnisse A und A/B werden als Elternmuster hinzugefügt. Die resultierende Sparse-Checkout-Datei ist nun

/*
!/*/
/A/
!/A/*/
/A/B/
!/A/B/*/
/A/B/C/

Hier spielt die Reihenfolge eine Rolle, daher werden die negativen Muster von den positiven Mustern, die weiter unten in der Datei erscheinen, überschrieben.

Sofern core.sparseCheckoutCone nicht explizit auf false gesetzt ist, parst Git die Sparse-Checkout-Datei und erwartet Muster dieser Typen. Git warnt, wenn die Muster nicht übereinstimmen. Wenn die Muster dem erwarteten Format entsprechen, verwendet Git schnellere hashbasierte Algorithmen, um die Aufnahme in den Sparse-Checkout zu berechnen. Wenn sie nicht übereinstimmen, verhält sich Git so, als wäre core.sparseCheckoutCone false, unabhängig von seiner Einstellung.

Im Kegelmodus-Fall, obwohl vollständige Muster in die Datei $GIT_DIR/info/sparse-checkout geschrieben werden, listet der Unterbefehl git sparse-checkout list die Verzeichnisse auf, die die rekursiven Muster definieren. Für die obige Beispiel-Sparse-Checkout-Datei ist die Ausgabe wie folgt:

$ git sparse-checkout list
A/B/C

Wenn core.ignoreCase=true ist, verwendet der Mustervergleichsalgorithmus eine Groß-/Kleinschreibung ignorierende Prüfung. Dies korrigiert falsch geschriebene Dateinamen im Befehl git sparse-checkout set, um den erwarteten Kegel im Arbeitsbaum widerzuspiegeln.

INTERNALS — SUBMODULE

Wenn Ihr Repository ein oder mehrere Submodule enthält, werden die Submodule basierend auf der Interaktion mit dem Befehl git submodule gefüllt. Insbesondere stellt git submodule init -- <path> sicher, dass das Submodule unter <path> vorhanden ist, während git submodule deinit [-f] -- <path> die Dateien für das Submodule unter <path> entfernt (einschließlich aller nicht verfolgten Dateien, uncommitteten Änderungen und ungesendeten Verlaufs). Ähnlich wie beim Sparse-Checkout, das Dateien aus dem Arbeitsbaum entfernt, aber Einträge im Index belässt, werden deinitialisierte Submodule aus dem Arbeitsbaum entfernt, haben aber weiterhin einen Eintrag im Index.

Da Submodule ungesendete Änderungen oder nicht verfolgte Dateien haben können, könnte deren Entfernung zu Datenverlust führen. Daher wird die Änderung der Sparse-Ein-/Ausschlussregeln nicht dazu führen, dass ein bereits ausgechecktes Submodule aus der Arbeitskopie entfernt wird. Anders ausgedrückt: So wie checkout nicht dazu führt, dass Submodule automatisch entfernt oder initialisiert werden, selbst wenn zwischen Zweigen gewechselt wird, die Submodule entfernen oder hinzufügen, führt die Verwendung von sparse-checkout zur Reduzierung oder Erweiterung des Umfangs von "interessanten" Dateien nicht dazu, dass Submodule automatisch deinitialisiert oder initialisiert werden.

Darüber hinaus bedeuten die oben genannten Fakten, dass es mehrere Gründe gibt, warum "verfolgte" Dateien möglicherweise nicht in der Arbeitskopie vorhanden sind: Anwendung von Sparsity-Mustern durch Sparse-Checkout und Status der Submodule-Initialisierung. Daher können Befehle wie git grep, die auf verfolgte Dateien im Arbeitsbaum angewendet werden, Ergebnisse zurückgeben, die durch eine oder beide dieser Einschränkungen begrenzt sind.

SIEHE AUCH

git-read-tree[1] gitignore[5]

GIT

Teil der git[1] Suite