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

NAME

git-fsck - Überprüft die Konnektivität und Gültigkeit der Objekte in der Datenbank

SYNOPSIS

git fsck [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
	 [--[no-]full] [--strict] [--verbose] [--lost-found]
	 [--[no-]dangling] [--[no-]progress] [--connectivity-only]
	 [--[no-]name-objects] [--[no-]references] [<object>…​]

BESCHREIBUNG

Überprüft die Konnektivität und Gültigkeit der Objekte in der Datenbank.

OPTIONEN

<Objekt>

Ein Objekt, das als Kopf einer Unreachability-Spur behandelt werden soll.

Wenn keine Objekte angegeben werden, verwendet git fsck standardmäßig die Indexdatei, alle SHA-1-Referenzen im refs-Namensraum und alle Reflogs (es sei denn, --no-reflogs wird angegeben) als Köpfe.

--unreachable

Gibt Objekte aus, die existieren, aber von keinem der Referenzknoten erreichbar sind.

--dangling
--no-dangling

Gibt Objekte aus, die existieren, aber niemals *direkt* verwendet werden (Standard). --no-dangling kann verwendet werden, um diese Information aus der Ausgabe wegzulassen.

--root

Berichtet über Wurzelknoten.

--tags

Berichtet über Tags.

--cache

Berücksichtigt jedes im Index aufgezeichnete Objekt als Kopfknoten für eine Unreachability-Spur.

--no-reflogs

Betrachtet Commits, die nur durch einen Eintrag in einem Reflog referenziert werden, nicht als erreichbar. Diese Option dient nur zur Suche nach Commits, die sich früher in einem Ref befanden, aber jetzt nicht mehr, aber immer noch in dem entsprechenden Reflog enthalten sind.

--full

Überprüft nicht nur Objekte im GIT_OBJECT_DIRECTORY ($GIT_DIR/objects), sondern auch diejenigen, die in alternativen Objektpools in GIT_ALTERNATE_OBJECT_DIRECTORIES oder $GIT_DIR/objects/info/alternates sowie in gepackten Git-Archiven in $GIT_DIR/objects/pack und entsprechenden Pack-Unterverzeichnissen in alternativen Objektpools gefunden werden. Dies ist jetzt Standard; Sie können es mit --no-full deaktivieren.

--connectivity-only

Überprüft nur die Konnektivität von erreichbaren Objekten und stellt sicher, dass alle von einem erreichbaren Tag, Commit oder Baum referenzierten Objekte vorhanden sind. Dies beschleunigt den Vorgang, da Blobs nicht vollständig gelesen werden müssen (obwohl immer noch überprüft wird, ob referenzierte Blobs existieren). Dies erkennt Korruption in Commits und Bäumen, führt aber keine semantischen Prüfungen durch (z. B. auf Formatfehler). Korruption in Blob-Objekten wird überhaupt nicht erkannt.

Nicht erreichbare Tags, Commits und Bäume werden ebenfalls angesprochen, um die Spitzen von hängenden Geschichtssegmenten zu finden. Verwenden Sie --no-dangling, wenn Sie diese Ausgabe nicht benötigen und den Vorgang weiter beschleunigen möchten.

--strict

Aktiviert eine strengere Überprüfung, insbesondere um einen Dateimodus zu erfassen, bei dem das g+w-Bit gesetzt ist, was von älteren Git-Versionen erstellt wurde. Bestehende Repositories, einschließlich des Linux-Kernels, Git selbst und Sparse-Repositories, enthalten alte Objekte, die diese Prüfung auslösen, aber es wird empfohlen, neue Projekte mit dieser Option zu überprüfen.

--verbose

Sei gesprächig.

--lost-found

Schreibt hängende Objekte in .git/lost-found/commit/ oder .git/lost-found/other/, je nach Typ. Wenn das Objekt ein Blob ist, werden die Inhalte in die Datei geschrieben, anstatt deren Objektname.

--name-objects

Beim Anzeigen von Namen erreichbarer Objekte wird zusätzlich zur SHA-1 ein Name angezeigt, der beschreibt, *wie* sie erreichbar sind, kompatibel mit git-rev-parse[1], z. B. HEAD@{1234567890}~25^2:src/.

--progress
--no-progress

Der Fortschritt wird standardmäßig auf dem Standardfehlerstrom gemeldet, wenn dieser an ein Terminal angeschlossen ist, es sei denn, --no-progress oder --verbose ist angegeben. --progress erzwingt die Fortschrittsanzeige, auch wenn der Standardfehlerstrom nicht an ein Terminal umgeleitet wird.

--references
--no-references

Steuert, ob die Konsistenz der Referenzdatenbank über git refs verify überprüft wird. Siehe git-refs[1] für Details. Standardmäßig wird die Referenzdatenbank überprüft.

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.

fsck.<msg-id>

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

Das Setzen von fsck.<msg-id> wird von git-fsck[1] übernommen, aber um Pushes solcher Daten zu akzeptieren, setzen Sie stattdessen receive.fsck.<msg-id>, oder um sie zu klonen oder zu fetchen, setzen Sie fetch.fsck.<msg-id>.

Der Rest der Dokumentation diskutiert fsck.* der Kürze halber, aber dasselbe gilt für die entsprechenden receive.fsck.* und fetch.fsck.*. Variablen.

Im Gegensatz zu Variablen wie color.ui und core.editor fallen die Variablen receive.fsck.<msg-id> und fetch.fsck.<msg-id> nicht auf die Konfiguration fsck.<msg-id> zurück, wenn sie nicht gesetzt sind. Um die gleichen fsck-Einstellungen unter verschiedenen Umständen einheitlich zu konfigurieren, müssen alle drei auf die gleichen Werte gesetzt werden.

Wenn fsck.<msg-id> gesetzt ist, können Fehler in Warnungen und umgekehrt umgewandelt werden, indem die Einstellung fsck.<msg-id> konfiguriert wird, wobei <msg-id> die fsck-Nachrichten-ID und der Wert entweder error, warn oder ignore ist. Zur Vereinfachung stellt fsck der Fehlermeldung/Warnung die Nachrichten-ID voran, z. B. "missingEmail: invalid author/committer line - missing email" bedeutet, dass die Einstellung fsck.missingEmail = ignore dieses Problem ausblendet.

Im Allgemeinen ist es besser, vorhandene Objekte mit Problemen mit fsck.skipList aufzulisten, anstatt die Art der Fehler aufzulisten, die diese problematischen Objekte gemeinsam haben, um ignoriert zu werden, da Letzteres neue Instanzen derselben Fehler unbemerkt lassen würde.

Das Setzen eines unbekannten fsck.<msg-id>-Wertes führt dazu, dass fsck abstürzt, aber dasselbe für receive.fsck.<msg-id> und fetch.fsck.<msg-id> führt nur dazu, dass git eine Warnung ausgibt.

Siehe den Abschnitt Fsck Messages in git-fsck[1] für unterstützte Werte von <msg-id>.

fsck.skipList

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

Dieses Feature ist nützlich, wenn ein etabliertes Projekt akzeptiert werden soll, obwohl frühe Commits Fehler enthalten, die sicher ignoriert werden können, wie z. B. ungültige Absender-E-Mail-Adressen. Hinweis: Beschädigte Objekte können mit dieser Einstellung nicht übersprungen werden.

Wie fsck.<msg-id> hat diese Variable entsprechende Varianten receive.fsck.skipList und fetch.fsck.skipList.

Im Gegensatz zu Variablen wie color.ui und core.editor fallen die Variablen receive.fsck.skipList und fetch.fsck.skipList nicht auf die Konfiguration fsck.skipList zurück, wenn sie nicht gesetzt sind. Um die gleichen fsck-Einstellungen unter verschiedenen Umständen einheitlich zu konfigurieren, müssen alle drei auf die gleichen Werte gesetzt werden.

Ältere Git-Versionen (vor 2.20) dokumentierten, dass die Liste der Objektnamen sortiert sein sollte. Dies war nie eine Anforderung; die Objektnamen konnten in beliebiger Reihenfolge erscheinen, aber beim Lesen der Liste verfolgten wir, ob die Liste für die Zwecke einer internen binären Suchimplementierung sortiert war, die sich mit einer bereits sortierten Liste etwas Arbeit sparen konnte. Solange Sie keine riesige Liste hatten, gab es keinen Grund, sich besonders anzustrengen, die Liste vorab zu sortieren. Nach Git Version 2.20 wird stattdessen eine Hash-Implementierung verwendet, so dass es keinen Grund mehr gibt, die Liste vorab zu sortieren.

DISKUSSION

git-fsck testet die SHA-1 und allgemeine Objekt-Integrität und führt eine vollständige Nachverfolgung der resultierenden Erreichbarkeit und allem anderen durch. Es gibt alle gefundenen Korruptionen aus (fehlende oder fehlerhafte Objekte) und wenn Sie die Option --unreachable verwenden, gibt es auch Objekte aus, die existieren, aber von keinem der angegebenen Kopfknoten (oder der Standardmenge, wie oben erwähnt) erreichbar sind.

Alle fehlerhaften Objekte, die Sie finden, müssen Sie aus Sicherungen oder anderen Archiven wiederherstellen (d. h. Sie können sie einfach löschen und einen rsync mit einer anderen Seite durchführen, in der Hoffnung, dass jemand anderes das Objekt hat, das Sie beschädigt haben).

Wenn core.commitGraph true ist, wird auch die Commit-Graph-Datei mit git commit-graph verify überprüft. Siehe git-commit-graph[1].

Extrahierte Diagnostik

unreachable <Typ> <Objekt>

Das <Typ>-Objekt <Objekt> wird tatsächlich nicht direkt oder indirekt in einem der gesehenen Bäume oder Commits referenziert. Dies kann bedeuten, dass es einen anderen Wurzelknoten gibt, den Sie nicht angeben, oder dass der Baum beschädigt ist. Wenn Sie keinen Wurzelknoten übersehen haben, können Sie nicht erreichbare Knoten genauso gut löschen, da sie nicht verwendet werden können.

missing <Typ> <Objekt>

Das <Typ>-Objekt <Objekt> wird referenziert, ist aber nicht in der Datenbank vorhanden.

dangling <Typ> <Objekt>

Das <Typ>-Objekt <Objekt> ist in der Datenbank vorhanden, wird aber niemals *direkt* verwendet. Ein hängender Commit könnte ein Wurzelknoten sein.

hash mismatch <Objekt>

Die Datenbank hat ein Objekt, dessen Hash nicht mit dem Wert der Objektbank übereinstimmt. Dies weist auf ein ernsthaftes Datenintegritätsproblem hin.

FSCK-MELDUNGEN

Die folgende Liste zeigt die Arten von Fehlern, die git fsck erkennt, und was jeder Fehler bedeutet, mit seiner Standard-Schweregrad. Der Schweregrad des Fehlers, abgesehen von denen, die als "(FATAL)" gekennzeichnet sind, kann durch Setzen der entsprechenden fsck.<msg-id> Konfigurationsvariable angepasst werden.

badDate

(ERROR) Ungültiges Datumsformat in einer Autor/Commiter-Zeile.

badDateOverflow

(ERROR) Ungültiger Datumswert in einer Autor/Commiter-Zeile.

badEmail

(ERROR) Ungültiges E-Mail-Format in einer Autor/Commiter-Zeile.

badFilemode

(INFO) Ein Baum enthält einen ungültigen Dateimodus-Eintrag.

badGpgsig

(ERROR) Ein Tag enthält eine ungültige (abgeschnittene) Signatur (z. B. gpgsig) Kopfzeile.

badHeaderContinuation

(ERROR) Eine Fortsetzungskopfzeile (wie für gpgsig) ist unerwartet abgeschnitten.

badName

(ERROR) Ein Autor-/Commiter-Name ist leer.

badObjectSha1

(ERROR) Ein Objekt hat eine ungültige SHA-1.

badPackedRefEntry

(ERROR) Die Datei "packed-refs" enthält einen ungültigen Eintrag.

badPackedRefHeader

(ERROR) Die Datei "packed-refs" enthält eine ungültige Kopfzeile.

badParentSha1

(ERROR) Ein Commit-Objekt hat eine ungültige Eltern-SHA-1.

badRefContent

(ERROR) Ein Ref hat fehlerhaften Inhalt.

badRefFiletype

(ERROR) Ein Ref hat einen ungültigen Dateityp.

badRefName

(ERROR) Ein Ref hat ein ungültiges Format.

badReferentName

(ERROR) Der Referenzname eines Symref ist ungültig.

badReftableTableName

(WARN) Eine Reftable-Tabelle hat einen ungültigen Namen.

badTagName

(INFO) Ein Tag hat ein ungültiges Format.

badTimezone

(ERROR) Ungültige Zeitzone in einer Autor/Commiter-Zeile gefunden.

badTree

(ERROR) Ein Baum kann nicht geparst werden.

badTreeSha1

(ERROR) Ein Baum hat ein ungültiges Format.

badType

(ERROR) Ungültiger Objekttyp gefunden.

duplicateEntries

(ERROR) Ein Baum enthält doppelte Dateieinträge.

emptyName

(WARN) Ein Pfad enthält einen leeren Namen.

emptyPackedRefsFile

(INFO) Die Datei "packed-refs" ist leer. Melden Sie dies an die git@vger.kernel.org Mailingliste, wenn Sie diesen Fehler sehen. Da nur sehr frühe Git-Versionen eine solche leere "packed_refs"-Datei erstellen würden, könnten wir diese Regel in Zukunft verschärfen.

extraHeaderEntry

(IGNORE) Zusätzliche Kopfzeilen nach tagger gefunden.

fullPathname

(WARN) Ein Pfad enthält den vollständigen Pfad beginnend mit "/".

gitattributesBlob

(ERROR) Ein Nicht-Blob gefunden unter .gitattributes.

gitattributesLarge

(ERROR) Der Blob .gitattributes ist zu groß.

gitattributesLineLength

(ERROR) Der Blob .gitattributes enthält zu lange Zeilen.

gitattributesMissing

(ERROR) Konnte den Blob .gitattributes nicht lesen.

gitattributesSymlink

(INFO) .gitattributes ist ein Symlink.

gitignoreSymlink

(INFO) .gitignore ist ein Symlink.

gitmodulesBlob

(ERROR) Ein Nicht-Blob gefunden unter .gitmodules.

gitmodulesLarge

(ERROR) Die Datei .gitmodules ist zu groß zum Parsen.

gitmodulesMissing

(ERROR) Konnte den Blob .gitmodules nicht lesen.

gitmodulesName

(ERROR) Ein Submodulname ist ungültig.

gitmodulesParse

(INFO) Konnte den Blob .gitmodules nicht parsen.

gitmodulesPath

(ERROR) Der Pfad .gitmodules ist ungültig.

gitmodulesSymlink

(ERROR) .gitmodules ist ein Symlink.

gitmodulesUpdate

(ERROR) Ungültige Submodul-Update-Einstellung gefunden.

gitmodulesUrl

(ERROR) Ungültige Submodul-URL gefunden.

hasDot

(WARN) Ein Baum enthält einen Eintrag namens ..

hasDotdot

(WARN) Ein Baum enthält einen Eintrag namens ...

hasDotgit

(WARN) Ein Baum enthält einen Eintrag namens .git.

largePathname

(WARN) Ein Baum enthält einen Eintrag mit einem sehr langen Pfadnamen. Wenn der Wert von fsck.largePathname einen Doppelpunkt enthält, wird dieser Wert als maximal zulässige Länge verwendet (z. B. "warn:10" würde jeden Pfadkomponenten von 11 oder mehr Bytes beanstanden). Der Standardwert ist 4096.

mailmapSymlink

(INFO) .mailmap ist ein Symlink.

missingAuthor

(ERROR) Autor fehlt.

missingCommitter

(ERROR) Committer fehlt.

missingEmail

(ERROR) E-Mail fehlt in einer Autor/Commiter-Zeile.

missingNameBeforeEmail

(ERROR) Fehlender Name vor einer E-Mail in einer Autor/Commiter-Zeile.

missingObject

(ERROR) Fehlende object-Zeile im Tag-Objekt.

missingSpaceBeforeDate

(ERROR) Fehlendes Leerzeichen vor dem Datum in einer Autor/Commiter-Zeile.

missingSpaceBeforeEmail

(ERROR) Fehlendes Leerzeichen vor der E-Mail in einer Autor/Commiter-Zeile.

missingTag

(ERROR) Unerwartetes Ende nach der type-Zeile in einem Tag-Objekt.

missingTagEntry

(ERROR) Fehlende tag-Zeile in einem Tag-Objekt.

missingTaggerEntry

(INFO) Fehlende tagger-Zeile in einem Tag-Objekt.

missingTree

(ERROR) Fehlende tree-Zeile in einem Commit-Objekt.

missingType

(ERROR) Ungültiger Typwert in der type-Zeile in einem Tag-Objekt.

missingTypeEntry

(ERROR) Fehlende type-Zeile in einem Tag-Objekt.

multipleAuthors

(ERROR) Mehrere Autor-Zeilen in einem Commit gefunden.

nulInCommit

(WARN) NUL-Byte im Body des Commit-Objekts gefunden.

nulInHeader

(FATAL) NUL-Byte im Objekt-Header vorhanden.

nullSha1

(WARN) Baum enthält Einträge, die auf eine Null-SHA-1 verweisen.

packedRefEntryNotTerminated

(ERROR) Die Datei "packed-refs" enthält einen Eintrag, der nicht durch einen Zeilenumbruch abgeschlossen ist.

packedRefUnsorted

(ERROR) Die Datei "packed-refs" ist nicht sortiert.

refMissingNewline

(INFO) Ein loser Ref, der nicht mit einem Zeilenumbruch (LF) endet. Da gültige Git-Implementierungen nie eine solche lose Ref-Datei erstellt haben, könnte dies in Zukunft zu einem Fehler werden. Melden Sie dies an die git@vger.kernel.org Mailingliste, wenn Sie diesen Fehler sehen, da wir wissen müssen, welche Tools eine solche Datei erstellt haben.

symlinkRef

(INFO) Ein symbolischer Link wird als Symref verwendet. Melden Sie dies an die git@vger.kernel.org Mailingliste, wenn Sie diesen Fehler sehen, da wir die Machbarkeit der Unterstützung für das Erstellen von symbolischen Links als Symrefs bewerten.

symrefTargetIsNotARef

(INFO) Das Ziel einer symbolischen Referenz verweist weder auf eine Wurzelreferenz noch auf eine Referenz, die mit "refs/" beginnt. Obwohl wir das Erstellen eines Symrefs zulassen, das auf den Referenz außerhalb von "ref" verweist, indem git symbolic-ref verwendet wird, könnten wir die Regel in Zukunft verschärfen. Melden Sie dies an die git@vger.kernel.org Mailingliste, wenn Sie diesen Fehler sehen, da wir wissen müssen, welche Tools eine solche Datei erstellt haben.

trailingRefContent

(INFO) Ein loser Ref hat nachgestellte Inhalte. Da gültige Git-Implementierungen nie eine solche lose Ref-Datei erstellt haben, könnte dies in Zukunft zu einem Fehler werden. Melden Sie dies an die git@vger.kernel.org Mailingliste, wenn Sie diesen Fehler sehen, da wir wissen müssen, welche Tools eine solche Datei erstellt haben.

treeNotSorted

(ERROR) Ein Baum ist nicht korrekt sortiert.

unknownType

(ERROR) Unbekannter Objekttyp gefunden.

unterminatedHeader

(FATAL) Fehlende Zeilenende im Objekt-Header.

zeroPaddedDate

(ERROR) Null-aufgefülltes Datum in einer Autor/Commiter-Zeile gefunden.

zeroPaddedFilemode

(WARN) Null-aufgefüllter Dateimodus in einem Baum gefunden.

Umgebungsvariablen

GIT_OBJECT_DIRECTORY

wird verwendet, um die Objektbank-Wurzel anzugeben (normalerweise $GIT_DIR/objects)

GIT_INDEX_FILE

wird verwendet, um die Indexdatei des Index anzugeben

GIT_ALTERNATE_OBJECT_DIRECTORIES

wird verwendet, um zusätzliche Objektbank-Wurzeln anzugeben (normalerweise nicht gesetzt)

GIT

Teil der git[1] Suite