Что я могу сделать с повреждением Git из-за недостающего объекта?

Я просто пошел клонировать репозиторий на другом удаленном сервере и столкнулся с проблемой, пытаясь сделать это:

git clone [email protected]:blah/blah/docs.git
Cloning into docs...
remote: Counting objects: 343, done.
remote: error: unable to find 14f87a739828e4d489b0310a51e057b30333926e
remote: Compressing objects: 100% (325/325), done.
error: git upload-pack: git-pack-objects died with error.   
fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
remote: fatal: unable to read 14f87a739828e4d489b0310a51e057b30333926e
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed

Я сделал небольшое исследование и узнал о git fsck, вот вывод:

$ git fsck --full
error: sha1 mismatch 14f87a739828e4d489b0310a51e057b30333926e

error: 14f87a739828e4d489b0310a51e057b30333926e: object corrupt or missing
missing blob 14f87a739828e4d489b0310a51e057b30333926e

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

Я все еще могу нажать на мой центральный удаленный репозиторий, но я не могу его клонировать.

14f87a739828e4d489b0310a51e057b30333926e - это blob, который является файлом отметки в корне репозитория. Я попробовал удалить этот файл и нажимать эти изменения безрезультатно.

Изменить: Можно ли импортировать историю git из другого репо? Я думаю, что могу просто начать новое репо и скопировать в него свои файлы, а затем импортировать историю фиксации.

Ответы

Ответ 2

Если это только один файл и он еще не упакован, вы сможете найти его в .git/objects/14/f87a739828e4d489b0310a51e057b30333926e в локальном репозитории. Вы можете скопировать эти файлы в соответствующий каталог в репозитории на вашем сервере.

Если он упакован, вы можете его распаковать, используя git unpack-objects в одном из файлов пакета в .git/objects/pack/. После этого копирование на сервер работает так, как описано выше.

Ответ 3

Простой push не устранит эту проблему, потому что git видит, что у нее есть фиксация, которая ссылается на поврежденный файл, и предположим, что она имеет все необходимые ей объекты.

У вас есть другой репозиторий с проектом, который не сообщает о каких-либо проблемах с fsck (и имеет ли этот файл)? Например. на вашей локальной машине? Чем вы должны попробовать:

  • Отложите поврежденный репозиторий.
  • Клонировать хороший репозиторий в нем.
  • Нажимайте любые ветки старого хранилища из других репозиториев или старого репозитория.

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

Примечание. Хотя на всех дисках есть хотя бы несколько контрольных сумм, у большинства чипов памяти нет ни одного, поэтому ошибка памяти скорее всего останется незамеченной, чем ошибка диска. memtest86 + - хороший способ проверить память.