Git: «Поврежденный свободный объект»

Question

Всякий раз, когда я вытаскиваю из своего пульта, я получаю следующую ошибку о сжатии.Когда я запускаю ручное сжатие, я получаю то же самое:

$ git gc
error: Could not read 3813783126d41a3200b35b6681357c213352ab31
fatal: bad tree object 3813783126d41a3200b35b6681357c213352ab31
error: failed to run repack

Кто-нибудь знает, что с этим делать?

Из файла cat я получаю следующее:

$ git cat-file -t 3813783126d41a3200b35b6681357c213352ab31
error: unable to find 3813783126d41a3200b35b6681357c213352ab31
fatal: git cat-file 3813783126d41a3200b35b6681357c213352ab31: bad file

И из git fsck я получил (не знаю, действительно ли это связано):

$ git fsck
error: inflate: data stream error (invalid distance too far back)
error: corrupt loose object '45ba4ceb93bc812ef20a6630bb27e9e0b33a012a'
fatal: loose object 45ba4ceb93bc812ef20a6630bb27e9e0b33a012a (stored in .git/objects/45/ba4ceb93bc812ef20a6630bb27e9e0b33a012a) is corrupted

Может кто-нибудь помочь мне расшифровать это?

Answer 1

Я получил эту ошибку после того, как мой (Windows) компьютер решил перезагрузить себя. К счастью, мое удаленное репо было обновлено, поэтому я просто сделал свежий клон git ..

Answer 2

В ответе @ user1055643 отсутствует последний шаг:

$ rm -fr .git
$ git init
$ git remote add origin your-git-remote-url
$ git fetch
$ git reset --hard origin/master
$ git branch --set-upstream-to=origin/master master  

Answer 3

Я следовал за многими другими шагами здесь; Описание Линуса о том, как посмотреть на дерево / объекты git и найти то, чего не хватает, было особенно полезно. git-git восстанавливает поврежденный блоб

Но, в конце концов, у меня были незакрепленные / поврежденные объекты дерева, вызванные частичным отказом диска, и объекты дерева не так легко восстановить / не охватывать этим документом.

В конце концов, я убрал конфликтующий objects/<ha>/<hash> с пути и использовал git unpack-objects с пакетом файлов из достаточно современного клона. Ему удалось восстановить отсутствующие объекты дерева.

Тем не менее, у меня осталось много висячих блобов, которые могут быть побочным эффектом распаковки ранее заархивированных файлов, и адресовано в других вопросах здесь

Answer 4

Я решил так: я решил просто скопировать не поврежденный объектный файл из клона резервной копии в мой исходный репозиторий.Это сработало так же хорошо.(Кстати: если вы не можете найти объект в .git / objects / по его имени, он, вероятно, был [упакован] [упакован] для экономии места.)

Answer 5

Для меня это произошло из-за сбоя питания при выполнении git push.

Сообщения выглядели так:

$ git status
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
fatal: loose object c238824eb3fb602edc2c49fccb535f9e53951c74 (stored in .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74) is corrupt

Я пробовал что-то вроде git fsck, но это нене поможетТак как сбой произошел во время git push, это, очевидно, произошло во время перезаписи на стороне клиента, которая происходит после обновления сервера.Я оглянулся и понял, что c2388 в моем случае является объектом коммита, потому что на него ссылаются записи в .git/refs.Так что я знал, что смогу найти c2388, когда посмотрю историю (через веб-интерфейс или второй клон).

На втором клоне я сделал git log -n 2 c2388, чтобы определить предшественникаc2388.Затем я вручную изменил .git/refs/heads/master и .git/refs/remotes/origin/master, чтобы они стали предшественником c2388 вместо c2388.Тогда я мог бы сделать git fetch.git fetch не удалось несколько раз для конфликтов на пустых объектах.Я удалял каждый из этих пустых объектов, пока git fetch не удалось.Это исцелило хранилище.

Answer 6

Runnning git stash; git stash pop исправил мою проблему

Answer 7

Когда у меня возникла эта проблема, я зарезервировал свои последние изменения (поскольку я знал, что я изменил), а затем удалил файл, на который он жаловался, в .git / location. Затем я сделал git pull. Будьте осторожны, это может не сработать для вас.

Answer 8

Просто удалите папку .git и добавьте ее снова.Это простое решение сработало для меня.

Answer 9

У меня просто была такая проблема.Моя конкретная проблема была вызвана сбоем системы, который повредил самый последний коммит (и, следовательно, также главную ветку).Я не толкнул и хотел сделать этот коммит заново.В моем конкретном случае я смог разобраться с этим следующим образом:

1. Сделайте резервную копию .git/: rsync -a .git/ git-bak/
2. Проверьте .git/logs/HEAD и найдите последнийстрока с действительным идентификатором фиксации.Для меня это был второй самый последний коммит.Это было хорошо, потому что у меня все еще были версии файла рабочего каталога, и поэтому все версии, которые я хотел.
3. Создайте ветку при этом коммите: git branch temp <commit-id>
4. повторно выполнитепрерванный коммит с файлами в рабочем каталоге.
5. git reset master temp, чтобы переместить основную ветвь на новый коммит, который вы сделали на шаге 2.
6. git checkout master и проверить, что он выглядит правильно сgit log.
7. git branch -d temp.
8. git fsck --full, и теперь должно быть безопасно удалить любые поврежденные объекты, найденные fsck.
9. Если все выглядит хорошо, попробуйте нажать.Если это сработает,

Это сработало для меня.Я подозреваю, что это довольно распространенный сценарий, поскольку наиболее вероятным будет повреждение самого последнего коммита, но если вы потеряете еще один назад, вы, вероятно, все еще можете использовать такой метод, с осторожным использованием git cherrypick,и reflog в .git/logs/HEAD.

Answer 10

У нас только что был случай здесь. Случилось так, что проблема была в том, что владельцем поврежденного файла был root, а не наш обычный пользователь. Это было вызвано фиксацией, выполненной на сервере после того, как кто-то сделал sudo su -.

Сначала идентифицируйте ваш поврежденный файл с помощью:

$> git fsck --full

Вы должны получить ответ, подобный этому:

fatal: loose object 11b25a9d10b4144711bf616590e171a76a35c1f9 (stored in .git/objects/11/b25a9d10b4144711bf616590e171a76a35c1f9) is corrupt

Перейдите в папку, где находится поврежденный файл, и выполните:

$> ls -la

Проверьте право собственности на поврежденный файл. Если это не так, просто вернитесь в корень вашего репо и выполните:

$> sudo chown -R YOURCORRECTUSER:www-data .git/

Надеюсь, это поможет!