Beschädigte Dateien in Git

Ich habe kürzlich einige Ordner mit dem folgenden Befehl aus meinem Git-Repos-Verlauf entfernt:

git filter-branch --index-filter 'git rm -r --cached var' -- --all

Leider kann ich nicht mehr aus diesen Repos ziehen. Dies ist der Fehlersatz, den ich bekomme:

git pull
remote: Counting objects: 3953, done.
remote: Compressing objects: 100% (2810/2810), done.
error: garbage at end of loose object '4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0'
fatal: object 4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0 is corrupted
fatal: index-pack failed

Eine freundliche Seele hat ein Skript geschrieben , um dies automatisch (und gründlicher) zu tun, aber der Prozess zur Wiederherstellung ist im Grunde folgender:

1. Untersuchen Sie die Datei, die Müll meldet, mit hexdump.

   $ hexdump .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0
   

   Sie suchen nach einem Teil der Datei, in dem es eine große Anzahl von Nullen gibt. Wenn es mehrere solcher Bereiche gibt, hatte ich viel Glück (N = 2), wenn ich nur den ersten riesigen Satz von Nullen betrachtete, selbst wenn sie kleine Durchläufe von Daten ungleich Null enthielten. Dies ist der "Müll", über den sich Git beschwert.

   ...
   0000500 0532 0302 0000 0000 0000 0000 0000 0000    # <-- Beginning here...
   0000510 0000 0000 0000 0000 0000 0000 0000 0000
   *
   0001000             # ... almost 3kb of zeros.
   

   Daraus können Sie die tatsächliche Größe des Objekts ermitteln. Hier wären es 0x504 oder 1.284 Bytes.

2. Erstellen Sie eine Sicherungskopie des Objekts. Wenn Sie den falschen Satz von Nullen auswählen, können Sie es erneut mit einem anderen Satz versuchen.

   $ cp .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0 ~/old_4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0
   

3. Schneiden Sie die Datei auf die entsprechende Länge ab.

   $ truncate -s 1284 .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0
   

Das beschädigte Objekt sollte jetzt behoben sein. Angenommen, es war das einzige, sollte das Klonen / Drücken / Ziehen des Repositorys nun wie erwartet funktionieren.

Unter Berufung auf meine Quellen glaube ich, dass ich das gleiche Problem hatte, aber in meinem Fall mit Ubuntu 10.4 (Kernel 2.6.32-23-generic). In diesem Fall handelt es sich um einen Dateisystemfehler, der noch nicht gefunden wurde. Es gibt ein offenes Problem zu ecryptfs zu diesem Thema und auch einen verwandten Usenet-Thread . Auf dem Weg zu einer Lösung fand ich eine praktische Antwort und Zusammenfassung auf StackOverflow. Der verlinkte Artikel war sehr interessant, obwohl ich letztendlich einen anderen Weg gegangen bin.