Git-Dateiintegrität

Kürzlich begann meine Hauptmaschine, die ich für die Entwicklung verwende, zu überhitzen. Ich fing an, 4 oder 5 Lockups pro Tag zu bekommen. Alles friert ein. Alle meine Projekte unterliegen der Versionskontrolle mit Git.

Ich erinnere mich, dass ich Linus ‘Vortrag bei Google gesehen habe, in dem er sagte, dass git sicherstellen wird, dass die Dateien nicht beschädigt sind. In meiner Situation kann man davon ausgehen, dass git mich warnt, wenn eine der Quelldateien beschädigt wird.

OS ist Mac OS X 10.4 Dateisystem ist HFS+.

Sie können Git zwingen, das gesamte Repository mit zu überprüfen git fsck. Wenn ein Git-Repository beschädigt wird, sollten Sie einen neuen Klon aus einem nicht beschädigten Repository erhalten.

Im normalen Betrieb sollte Git Teile des Repositorys beim Lesen überprüfen, daher kann es länger dauern, bis eine Beschädigung bemerkt wird, aber es Wille bemerken, wenn Sie zum ersten Mal versuchen, auf die beschädigten Daten zuzugreifen.

Was Linus meinte, als er sagte, dass Git sicherstellt, dass die Dateien nicht beschädigt sind, bezog sich auf die Tatsache, dass Sie es sind, wenn Sie sich auf ein bestimmtes Commit beziehen (identifiziert durch seinen Hash). garantiert dass es wird stets beziehen sich auf genau denselben Repository-Zustand. Wenn Sie den Linux-Kernel aus Linus’ Baum ziehen und er sich auf irgendeinen Commit ae6bcd1… bezieht, gibt es nichts, was Sie tun können (selbst in Ihrem lokalen Repository), damit Commit ae6bcd1… jemals anders aussieht als der begehen Linus betrachtet, wenn er sich darauf bezieht.

Da ein Commit-Objekt Verweise auf (alle) seine(n) übergeordnete(n) Commit(s) enthält, garantieren Sie außerdem, wenn Sie auf ein Commit verweisen, auch dessen vollständigen Verlauf im DAG.

Was die Dateibeschädigung angeht, ist es eine Art unabhängiges Problem. aber ohne die eigentlichen Blob-Objekte (z. B. .git/objects/ob/ject_hashname) zu beschädigen, wenn eine Ihrer Arbeitsbaumdateien beschädigt wird, können Sie von einem früheren Commit-Status oder von einem Index-/Cache-Status wiederherstellen.

Sie werden in diesem Fall niemals in der Lage sein, eine Remote zu beschädigen, es sei denn, Sie führen erzwungene Pushs durch (die den Verlauf auf Remotes überschreiben), da Push sicherstellt, dass die Commit-Objekte ein kontinuierliches Verlaufsdiagramm bilden.

Kürzlich musste ich die Repos auf einem abgestürzten Server überprüfen, ich habe den folgenden Befehl verwendet:

for gitdir in  $(sudo find / -name ".git" -type d -printf "%h "); do
  cd $gitdir && ( git fsck && echo "${gitdir} - "'HAPPY !' ) \
  || echo "${gitdir} - "'ERROR !';
done