Просмотреть осиротевшие коммиты в Git

Question

Мой репозиторий git почему-то пошёл не так, как надо - сегодня утром я загрузил msysgit, и вместо имени ветки, отображаемого после текущей директории, он говорит "((ref: re ...))", отчеты "git status" все как новый файл, 'git log' и 'git reflog' говорят мне "fatal: bad default revision 'HEAD'" и т. д.

Выполнение 'git reflog --all' или 'gitk --all' показывает мне, что остальная часть хранилища не повреждена, но похоже, что ветвь, над которой я работал, просто исчезла, что объясняет, почему HEAD не кажется существовать / указывать на что-либо.

Я знаю, что git хранит все виды информационных шаров, и я предполагаю, что мои коммиты как-то осиротели, так есть ли какая-нибудь команда, которая покажет мне эти коммиты, чтобы я мог сбросить HEAD к ним?

РЕДАКТИРОВАТЬ: О дорогой. Я обнаружил «git fsck», и «git fsck --full» сообщает «fatal: объект 03ca4 ... поврежден». Что, черт возьми, я могу с этим поделать?

РЕДАКТИРОВАТЬ: О дорогой о дорогой. Я извлек другую ветку, затем попытался воссоздать исходную ветку с тем же именем, используя git checkout -b lostbranchname, и git говорит: «ошибка: невозможно разрешить ссылку refs /heads / lostbranchname: нет ошибки, фатально: не удалось заблокировать ссылку для обновления: нет ошибок ". «Нет ошибок» должно быть особенно неприятной ошибкой. Похоже, он все еще висит, но не может быть использован и не может быть убит.

РЕДАКТИРОВАТЬ: Супер пупер ой дорогой. Я выполнил кучу распаковки, перепаковки и замены вещей, как было предложено здесь: Как восстановить объекты Git, поврежденные из-за сбоя жесткого диска? , но теперь я получаю еще один хеш-код как поврежденный для чего-то так же безобиден, как и «git status». Я думаю, что все это скрыто. Git хорош и все такое, но я не должен был бы иметь дело с такими вещами.

Answer 1

Вместо того, чтобы оставить это открытым, я думаю, что дам ответ на свой вопрос. Использование git reflog --all - это хороший способ просмотреть осиротевшие коммиты, а с помощью хэшей SHA1 вы можете восстановить историю.

В моем случае хранилище было повреждено, так что это не помогло; git fsck может помочь вам найти и иногда исправить ошибки в самом хранилище.

Answer 2

С git 2.9.x / 2.10 (3 квартал 2016 г.) вам больше не придется использовать git reflog --all, достаточно будет git reflog.

См. коммит 71abeb7 (03 июня 2016 г.) от SZEDER Gábor (szeder) .
^{(Объединено Junio ​​C Hamano - gitster - в коммит 7949837 , 06 июля 2016 г.)}

reflog: продолжить проходить reflog мимо корневых коммитов

Если репозиторий содержит более одного корневого коммита, то его рефлог HEAD может содержать несколько «событий создания», то есть записей, значение «from» которых равно null sha1.
Перечисление такого reflog в настоящее время преждевременно останавливается на первой такой записи, даже если reflog все еще содержит более старые записи.
Это может напугать пользователей, думая, что их reflog был усечен после 'git checkout --orphan'.

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

Answer 3

Хорошей особенностью git является то, что он обнаруживает коррупцию. Тем не менее, он не включает исправление ошибок для защиты от коррупции.

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

У меня нет опыта работы с git на windows, но я никогда не видел такого поведения с git на Linux или OS X.