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

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

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

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

ИЗМЕНИТЬ: О, дорогая. Я обнаружил "git fsck", а "git fsck --full" сообщает "фатальный: объект 03ca4... поврежден". Что, черт возьми, я могу с этим поделать?

ИЗМЕНИТЬ: О, дорогой, дорогой. Я проверил другую ветку, а затем попытался воссоздать исходную ветку с тем же именем, используя 'git checkout -b lostbranchname', а git говорит: "ошибка: не удалось разрешить ссылки refs/heads/lostbranchname: Нет ошибки, фатальный: не удалось заблокировать ref для обновления: нет ошибки". "Нет ошибки" должна быть особенно неприятной ошибкой. Таким образом, похоже, что он все еще висит вокруг, но не может быть использован и не может быть убит.

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

Ответ 1

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

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

Ответ 2

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

См. commit 71abeb7 (03 июня 2016 г.) SZEDER Gábor (szeder).
(объединено Junio ​​C Hamano - gitster - в совершить 7949837, 06 июля 2016 года)

reflog: продолжить прохождение reflog прошлого корня

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

Продолжайте повторять события, связанные с такими событиями создания, на основе превзойдя "новое" значение reflog.

Ответ 3

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

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

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