Ответ 1
Решение из http://vincesalvino.blogspot.ca/2013/08/git-empty-files-corrupt-objects-and.html позволило мне решить проблему:
find .git/objects/ -size 0 -exec rm -f {} \;
Непосредственно перед получением этой ошибки я сделал следующее:
[email protected]:~/file/path$ git add *
[email protected]:~/file/path$ git push
^C
[email protected]:~/file/path$ git commit -m "my commitmesg"
(Я впал в панику, потому что забыл добавить фиксацию перед нажатием, поэтому я cntrl + c'ed.
Теперь я получаю следующую ошибку из git fsck -full:
error: inflate: data stream error (incorrect header check)
error: corrupt loose object '5cdeb9c3a1fe164cb4d2779d1e0d9d9f4ef18c6a'
fatal: loose object 5cdeb9c3a1fe164cb4d2779d1e0d9d9f4ef18c6a (stored in .git/objects/5c/deb9c3a1fe164cb4d2779d1e0d9d9f4ef18c6a)
git cat-file -t 5cdeb9c3a1fe164cb4d2779d1e0d9d9f4ef18c6a возвращает, что этот объект является фиксацией.
После поиска, я нашел, как исправить это, если объект является blob, но не является ли это фиксацией.
Решение из http://vincesalvino.blogspot.ca/2013/08/git-empty-files-corrupt-objects-and.html позволило мне решить проблему:
find .git/objects/ -size 0 -exec rm -f {} \;
Сначала создайте резервную копию существующего репозитория. cp -r
или что-то в этом роде. Таким образом, если ваши попытки починить ваш репозиторий, это еще хуже, вы можете восстановить.
Проще всего попробовать заменить этот поврежденный файл объекта рабочим. Если у вас есть резервная копия вашего репозитория, используйте это. В противном случае сделайте git clone
из своего удаленного репозитория, чтобы получить новую копию и скопировать .git/objects/5c/deb9c3a1fe164cb4d2779d1e0d9d9f4ef18c6a
в существующий сломанный. Посмотрите, исправляет ли это.
спасибо за ответ. Я запустил это в новом клонированном репо и вернул, что он распаковал 100% объектов, однако они не были в .git/objects/pack этого репо.
Итак, вместо этого и попробовал что-то этим утром, которое сработало. 1. клонирование моего репозитория github в отдельный новый каталог. 2. Скопируйте локально измененные файлы (которые я хотел выполнить изначально) в мой новый клонированный репозиторий, а затем подтолкнули их к github. 3. уничтожил мой старый локальный репозиторий и 4. снова клонировал его на тот же путь к файлу, что и мой старый репозиторий.
Очень похоже на ответ Шверма, но мне пришлось запустить новое репо, в которое распаковывают файлы .pack
:
git clone <repo-uri> my_repo.fresh_clone
mkdir my_repo.newly_unpacked
cd !$
git init
for pack_file in ../my_repo.fresh_clone/.git/pack/*.pack; do
git unpack-objects < $pack_file
done
Затем я скопировал файлы из my_repo.newly_unpacked/.git/objects/<xx>/<sha1>
, как указано сообщениями об ошибках. Меня застали, потому что несколько операций, таких как git checkout
, отображали больше недостающих объектов, чем простой git status
, поэтому лучше всего держать каталоги восстановления немного до их очистки.
Простой ответ на этот вопрос для тех, кто сталкивается с этой проблемой: команда git clone - это исправление, если оно имеет удаленное репо, затем клонирует его в локальную папку (после удаления поврежденного локального репо), если у вас нет удаленного репо, попробуйте нажать коррумпированное репо в github, а затем клонировать его оттуда, я думаю, что поврежденные объекты не будут толкаться, и это устранит проблему.
У меня была аналогичная проблема, когда система разбилась перед выполнением фиксации. К счастью, все, что мне нужно было сделать, это снова клонировать полное репо в новый каталог и отказаться от старого.
Недавно клонированное репо не имело поврежденного файла .git/objects/# num/# hash, который был поврежден.