Исправление поврежденного свободного объекта в качестве фиксации в git

Непосредственно перед получением этой ошибки я сделал следующее:

[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, но не является ли это фиксацией.

Ответ 1

Решение из http://vincesalvino.blogspot.ca/2013/08/git-empty-files-corrupt-objects-and.html позволило мне решить проблему:

find .git/objects/ -size 0 -exec rm -f {} \;

Ответ 2

Сначала создайте резервную копию существующего репозитория. cp -r или что-то в этом роде. Таким образом, если ваши попытки починить ваш репозиторий, это еще хуже, вы можете восстановить.

Проще всего попробовать заменить этот поврежденный файл объекта рабочим. Если у вас есть резервная копия вашего репозитория, используйте это. В противном случае сделайте git clone из своего удаленного репозитория, чтобы получить новую копию и скопировать .git/objects/5c/deb9c3a1fe164cb4d2779d1e0d9d9f4ef18c6a в существующий сломанный. Посмотрите, исправляет ли это.

Ответ 3

спасибо за ответ. Я запустил это в новом клонированном репо и вернул, что он распаковал 100% объектов, однако они не были в .git/objects/pack этого репо.

Итак, вместо этого и попробовал что-то этим утром, которое сработало. 1. клонирование моего репозитория github в отдельный новый каталог. 2. Скопируйте локально измененные файлы (которые я хотел выполнить изначально) в мой новый клонированный репозиторий, а затем подтолкнули их к github. 3. уничтожил мой старый локальный репозиторий и 4. снова клонировал его на тот же путь к файлу, что и мой старый репозиторий.

Ответ 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, поэтому лучше всего держать каталоги восстановления немного до их очистки.

Ответ 5

Простой ответ на этот вопрос для тех, кто сталкивается с этой проблемой: команда git clone - это исправление, если оно имеет удаленное репо, затем клонирует его в локальную папку (после удаления поврежденного локального репо), если у вас нет удаленного репо, попробуйте нажать коррумпированное репо в github, а затем клонировать его оттуда, я думаю, что поврежденные объекты не будут толкаться, и это устранит проблему.

Ответ 6

У меня была аналогичная проблема, когда система разбилась перед выполнением фиксации. К счастью, все, что мне нужно было сделать, это снова клонировать полное репо в новый каталог и отказаться от старого.

Недавно клонированное репо не имело поврежденного файла .git/objects/# num/# hash, который был поврежден.