Ответ 1

Хорошо, так. Из второго сообщения об ошибке видно, что поврежденный объект, который вы перенесли, был фиксацией. (ГОЛОВА указывала на это!) К сожалению, это означает, что трудно вручную его восстановить. (К сожалению, это невозможно, если вы не можете точно помнить, что такое сообщение фиксации и какое время вы совершили коммит.) К счастью, это означает, что легко воскресить новую фиксацию с тем же содержимым файла - вы будете просто нужно написать для него новое сообщение.

Прежде чем начать, просмотрите содержимое .git/HEAD - если это имя ветки, помните, что для более позднего.

Во-первых, нам нужно выяснить, что должен был родитель этого коммита. Вы можете использовать git reflog, чтобы посмотреть заголовок HEAD, и найти SHA1, где HEAD был только что вы сделали commit 016660b. Он должен выглядеть примерно так:

016660b [email protected]{n}: commit: <subject of commit>
1234abc [email protected]{n-1}: ...

Вы можете скопировать SHA1 предыдущей позиции HEAD и проверить, что commit:

git checkout 1234abc

Затем вы можете прочитать в дереве, что ваша поврежденная фиксация имела:

git read-tree 2c1033501b82e301d47dbf53ba0a199003af25a8

И затем зафиксируйте!

git commit

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

git branch -d master       # remove the original master branch
git checkout -b master     # recreate it here

Если есть другие ветки, в которых содержится поврежденная фиксация, вам также нужно будет немного восстановить их - сообщите мне, нужна ли вам помощь.

Ответ 2

FWIW, вот ответ, который более практичен, чем много безнадежно оптимистичных по другим вопросам о поврежденных репозиториях git, большинство из которых делают необоснованное предположение о том, что плохой OP может "просто повторно клонировать с удаленного происхождение! Хм. Но. Подожди секунду. Что, если я источник?

Ужас

История начинается, когда попытка запустить простой git gc --aggressive показала, что, без ведома для меня, в какой-то момент моя полностью локальная ретрансляция git каким-то образом получила полный халат: он не смог зарегистрировать ничего за пределами нескольких месяцев назад, тем самым потеряв большую часть своей истории, и кричал gutturally всякий раз, когда его просили git fsck --full | grep -v dangling. Несколько объектов были идентифицированы как потерянные на git fsck.

git-repair: минимизация ужасающего ручного труда с 2014 года

После паники и поиска много вопросов с чрезмерно проголосовавшими плохими ответами, просто говоря "просто повторить клонирование из удаленного источника!" - что, позвольте мне выразить суть, у меня нет, потому что я источник - я нашел git-repair, сделал простой sudo aptitude install git-repair, и пусть он выполнит все утомительные автоматические исправления, которые, вероятно, заняли бы у меня часы (пожалуйста: запустите копию поврежденного репо [duh], без --force!)

Это помогло уменьшить количество ужасов, сообщенных git fsck --full | grep -v dangling. Но события за середину августа все еще недостижимы.

В частности, все это, казалось, было сосредоточено вокруг одного коммита, которого невозможно было получить. Как я мог его восстановить? Поиск не очень помог!

У вас есть резервная копия, правильно?

Здесь, где мне посчастливилось иметь резервную копию с конца ноября. Вы берете резервные копии, не так ли? В моем случае это была ручная zip-репо (моя ежедневная программа резервного копирования - это какая-то ужасная инкрементная вещь tar, которую я никогда не тестировал... a-cough)... но, пожалуйста, это было достаточно хорошо. Он не пострадал, как бы то ни было, что унизило мое живое репо.

Но отсутствующий объект, похоже, просто не хранился в этой резервной копии .git/objects/XY/RESTOFHASHBLAHBLAHBLAH. Вероятно, это был коммит, а не файл. Я не знаю! git - это волшебство для меня, навсегда превосходящее мою способность осмысливать. Я просто нуждался в исправлении, быстро. Не потому, что мы все здесь?

Восстановить объекты из резервной копии (что у вас есть, правда?)

С резервным копированием теперь в руке у меня была довольно глупая идея: "Нет, это не может работать!", и сразу же обнаружил, что просто наивно работает cp -fr /path/to/repo_backup/.git/objects/* /path/to/repo_git-repaired/.git/objects до с файлом слияние каталога .git/objects резервное копирование в свою копию в моем поврежденном, частично восстановленном репо... работало, чтобы восстановить всю историю - вернемся к хорошему ol initial commit lol. Доказательство исправления: git fsck --full тоже был счастлив (несмотря на все оборванные бит).

Затем я взял резервные копии живых/поврежденных, частично отремонтированных и, казалось бы, восстановленных репозиториев на отдельный диск, в случае, если мне понадобится их снова.

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

Бесконечные оговорки в бесконечных комбинациях

Теперь, очевидно, все это связано с предостережениями: вы должны попробовать все на копии вашего поврежденного репо, прочитать всю документацию, подумать о том, чтобы быть немного более осторожным, чем я был (что принудительно cp), и не держите меня ответственным или ответственным за абсолютно все, что пойдет не так *... но это дает вам что-то лучшее, чтобы попытаться, чем "просто повторить клонирование из удаленного источника!", правильно?

* Если, однако, все идет правильно, может быть сделано большое пожертвование.;)

Если кто-то нуждается во мне, я буду подозрительно смотреть в общем направлении на моем диске, надеюсь, придумает подпрограмму резервного копирования, которая не потребует двухзначных часов для восстановления (если вообще), и, возможно, даже немного поспав.

Ответ 3

У меня была та же проблема. Однако моя проблема была решена с изменением разрешений папок и подпапок .git/objects (рекурсивно) на сервере. Что-то вроде:

chmod -R 770 .git/objects

Я думаю, что это не ваша проблема, но в моем случае это было разрешено.