OK, ich habe es irgendwann selbst herausgefunden.
Kurzfassung: Ich habe das Commit geändert, das auf das beschädigte Blob zeigt, um es aus dem Verlauf zu entfernen.
Lange Version: Ich dachte, dass, da ich wusste, was die Datei war, und wollte es einfach aus dem Commit verschwinden lassen, dann konnte ich nur das alte Commit ändern. Ich habe nicht wirklich erwartet, dass es funktioniert, aber irgendwann hat es funktioniert.
Ich muss darauf hinweisen, dass ich den Blob in .git/objects in dem Versuch, vorherige Dinge zu entfernen, und es ist möglicherweise wichtig, warum es funktionierte.
Zuerst musste ich wissen, was es zu begehen war. Dafür verwendete ich den Befehl
git log --raw --all --full-history -- subdir/my-file
ich das gefunden wurde 966a46 genannt commit ....
Dann habe ich die Schritte, um es zu ändern. Da es sich um eine alte begehen war, habe ich
git rebase -- interactive 966a46^
Mein Redakteur mit einer Zeile kam für jede begehen, und ich änderte „Pick“ auf „Bearbeiten“ vor dem Commit ich ändern wollte.
Der Befehl git status zeigte mir, dass ich die Datei wurde geändert, um löschen wollte:
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: subdir/my-file
ich es von der commit entfernen wollte, so habe ich rm subdir/my-file. git status dann hat mir gezeigt:
# deleted: subdir/my-file
Das sah vielversprechend aus. So beging ich einfach die geänderte begehen und setzte die Fütterungsmaterial:
git commit --all --amend
git rebase --continue
aber nach ein paar umbasiert haben begeht es konnte nicht mit diesem Fehler:
error: could not apply 45c2315... did some fancy things
fatal: unable to read 95b6a826cadae849f4932a71d6735ab6ceb47cab
45c2315 wurde das erste, in dem commit meine Datei geändert wurde nachdem er erstellt wurde. Da die vorherige Version der Datei nicht gefunden wurde, ist sie einfach fehlgeschlagen.
git status hat mir gezeigt, unter anderem:
# Unmerged paths:
# (use "git reset HEAD <file>..." to unstage)
# (use "git add/rm <file>..." as appropriate to mark resolution)
#
# deleted by us: subdir/my-file
Ich bin eigentlich nicht sicher, was es bedeutet, aber dies sollte Festschreibung der erste sein, in dem die Datei nach dem Update erscheinen würde. Also wollte ich nicht, dass es gelöscht wird, sondern im Gegenteil, zusätzlich zum Commit! Also habe ich
git add subdir/my-file
Und sicher git status zeigte, dass es als eine „neue Datei“.
Dann habe ich git rebase --continue und alles ging gut, und die Rebase war ein Erfolg.
git push ging dann glatt anstatt über den gebrochenen Blob zu versagen.
Aber es gab immer noch ein Problem, weil git fsck noch versagt wurde:
$ git fsck --full
Checking object directories: 100% (256/256), done.
broken link from tree 27e8e7d5b94c1dad5410a8204089828a167a0eaf
to blob 95b6a826cadae849f4932a71d6735ab6ceb47cab
Und git gc scheiterte auch, wenn ich ihm alles zu beschneiden gefragt. Also habe ich herausgefunden, die beste Vorgehensweise war, da ich zuvor erfolgreich gedrängt hatte, alles wieder in ein neues Repository zu klonen und von dort aus zu arbeiten.
Versuchen Sie, einige der Lösungen hier zu betrachten: http://stackoverflow.com/q/4254389/1031900 –
Diese Frage bezieht sich auf einen beschädigten Baum, der ein bisschen anders ist. Keine dieser Antworten kann mir leider helfen. Ich werde ein paar Dinge versuchen und werde es hier posten, wenn sie funktionieren. –