Корень проблемы, скорее всего, заключается в том, что вы извлекли USB-ключ до или во время действия ОС по записи в USB-ключа. В результате осталось несколько поврежденных файлов.
Файлы, поврежденные из-за неправильного выключения компьютера по любой причине - одно из них - это извлечение USB-ключа, но также возможны сбои операционной системы, сбои питания, загорание компьютеров ии т. д., как правило, приводят к повреждению самых последних записанных файлов. Файлы, которые только что сидели тихо , как правило , остаются целыми. Здесь много предостережений, но этот общий принцип применим здесь.
Файлы, содержащие информацию о ветвях, могут быть повреждены, если вы обновляли ветки.
Здесь,поврежденные файлы включены .git/refs/heads/master. Этот файл должен содержать 41 байт, которые состоят из 40-байтового текстового представления идентификатора хеша коммита, который должен рассматриваться как конец ветви master, за которым следует символ новой строки ASCII. Не существует определенного способа догадаться , в котором коммит является правильным tip-коммитом , поэтому Git хранит ответ на вопрос "каков хэш-идентификатор коммита tip из master* в некоторых файлах.
(В некоторых случаях допустимый ответ может быть доступен в .git/packed-refs, но в целом, если существует .git/refs/heads/master, он должен содержать правильныйОтвет. Правильный ответ со временем изменяется, когда вы создаете новые коммиты, когда вы запускаете git reset, вы запускаете git branch -f и т. д.)
Поврежденные файлыможет включать .git/index, который содержит индекс Git или область подготовки . Оба термина означают одно и то же в Git, и есть третий, редко используемый термин, кэш для этого же файла. За исключением случаев, когда вы используете индекс для работы с конфликтующим объединением, материал в индексный файл в основном довольно легко переписать- вычислить с некоторыми усилиями: Git использует его для ускорения работы, т. е. в качестве кэша, следовательно,Третий редко используемый термин.
Если (как в большинстве случаев) в кеше нет ничего, что не может быть пересчитано, вы можете просто удалить .git/index и затем запустить git reset дляпересчитать это. Это привело бы к тому, что все сообщения "новый файл ..." исчезли бы, и единственное, что было потеряно, это то, были ли у вас какие-то особые обновления.
Слово в основном появляется здесь часто, потому чтоИндекс содержит хэш-идентификатор всех объектов BLOB-объектов («файлов»), которые вы намереваетесь добавить в свой следующий коммит. Если вы сделали что-то необычное, например, создали новую уникальную версию файла и поместили ее в индекс, а затем удалили ее повсюду, идентификатор хэша этой уникальной версии файла может быть непросто найти где-либо. Вы можете получить это при использовании git add -p или git reset -p для создания третьего варианта файла, который отличается как от принятой версии , так и от версии рабочего дерева. В этом случае удаление и повторное создание индекса (с помощью rm .git/index; git reset) позволит проще всего восстановить этот файл, если повторно выполнить операцию git add -p или git reset -p.
В вашем случаеКажется возможным, что индекс был полностью удален, что привело к тому, что Git заявил, что каждый файл был новым. Это то же самое, что вы получаете, если вы запускаете rm .git/index, так что вы можете также запустить git reset. Тем не менее, здесь определенно происходит что-то еще из-за этого сообщения:
error: ac2fcd052804fb7adac465220da5bcb04d008fc7: invalid sha1 pointer in cache-tree
cache-tree здесь ссылается на содержимое индекса, используя старое имя cache . Но поскольку это «кеш», удаление и повторное создание индекса может обойти проблему, в зависимости от других факторов.
В поврежденные файлы могут входить некоторые файлы вашего рабочего дерева. Git не может помочь вам в этом: эти файлы управляет остальная часть вашего компьютера. Git записывает копий файлов в ваше рабочее дерево, когда вы git checkout записываете какой-то существующий коммит, чтобы они были в форме, которую вы можете видеть и с которой работать, но после этого все это ваше / ваше-компьютер для управления.
Возможно, поврежденные файлы содержат некоторые из внутренних объектов Git. В вашем случае это, очевидно, произошло:
error: unable to unpack header of .git/objects/8f/1da374ffac3711f8cdde57379f90cb03bbb9ea
error: 8f1da374ffac3711f8cdde57379f90cb03bbb9ea: object corrupt or missing: .git/objects/8f/1da374ffac3711f8cdde57379f90cb03bbb9ea
Это означает, что объект 8f1da374ffac3711f8cdde57379f90cb03bbb9ea поврежден. Невозможно сказать, что это был за тип , тем более, какие данные были в нем и были ли они ценными, без дополнительной информации.
В число поврежденных файлов может входитьразличные reflogs, хранящиеся в .git/logs/. В этом случае вы получили:
invalid reflog entry 8f1da374ffac3711f8cdde57379f90cb03bbb9ea
и:
error: refs/heads/master: invalid reflog entry 8f1da374ffac3711f8cdde57379f90cb03bbb9ea
, используя этот же номер. Это идентификатор хэша поврежденного объекта, который мы видели всего минуту назад. Поскольку имена веток необходимы для указания на коммит объектов, теперь мы можем догадаться, что 8f1da374ffac3711f8cdde57379f90cb03bbb9ea был объектом коммита, прежде чем он был поврежден. Вероятно, это был недавно созданный коммит, например, сделанный git commit --amend.
Из всего этого мы можем сделать вывод - но это все еще предположение - что git commit --amend Сам коммит потерпел неудачу, и в качестве сломанного хеш-идентификатора в master должен был быть текст 8f1da374ffac3711f8cdde57379f90cb03bbb9ea. Вероятно, индекс был полностью поврежден или удален, но зачастую достаточно просто удалить его и перестроить его аспект кэша, чтобы вы могли удалить его снова (при необходимости), а затем пересобрать из текущего коммита, как только вы получите разумный «текущий коммит». ». Некоторые из ваших reflogs могут быть повреждены, но в любом случае все reflogs являются вспомогательными данными: в них нет ничего критичного для собственной работы Git, поэтому поврежденные могут быть усечены. Самая большая проблема - поврежденный файл .git/objects/.
Если вы хотите потерять этот коммит, может быть в порядке, просто удалив поврежденный объект и поместив действительный хэш-идентификатор в.git/refs/heads/master. Когда вы это сделали, ваш fsck все еще жаловался:
error: ac2fcd052804fb7adac465220da5bcb04d008fc7: invalid sha1 pointer in cache-tree
broken link from tree b0d598ef5427d59ed31eb1b315c761fc89af40b7
to tree ac2fcd052804fb7adac465220da5bcb04d008fc7
Теперь эта первая строка по-прежнему ссылается на что-то прочитанное из .git/index. Функция удаления и сброса перестроит индекс / кэш из выбранного вами коммита, записав его хэш-идентификатор в .git/refs/heads/master. Если древовидный объект ac2fcd052804fb7adac465220da5bcb04d008fc7 не используется где-либо еще в хранилище, это может оставить вас с целым хранилищем.
Если оно не , тем не менее,будет только два способа сделать этот конкретный репозиторий Git самосогласованным:
Удалить все коммиты и всех их потомков, если таковые имеются, которые ссылаются напрямуюили косвенно, к этому объекту дерева.
Получить или восстановить отсутствующий объект. Если он находится в каком-то другом Git-репозитории - некотором клоне этого - это простой способ получить его. Запустите git cat-file -p ac2fcd052804fb7adac465220da5bcb04d008fc7 в хранилище, в котором оно есть. Результатом является текстовое представление дерева. Используйте git hash-object -t tree -w для создания объекта в хранилище USB-ключа, чтобы он существовал сейчас.
Обратите внимание, что этот метод получения или реконструкции работает для любого поврежденный или отсутствующий объект: идентификатор хеша глобально уникален для каждого клона, поэтому, если вы можете найти объект в каком-либо другом клоне, вы можете скопировать объект из этот другой клон.
Вывод
как мне отремонтировать USB-ключ и другие репо из этого беспорядка?
ясный Можно использовать другой клон. Найдите неповрежденный клон того же хранилища. Сделайте клон этого клона, чтобы стать вашим новым результатом «отремонтированного клона». К этому новому клону добавьте новые объекты из поврежденного хранилища - новые теги, деревья, BLOB-объекты и коммиты - которые сами не повреждены. (Вы можете скопировать их напрямую, с помощью cp или использовать git cat-file -p <hash> | git hash-object -t <type> --stdin.) Таким образом, вы только читаете из поврежденный клон.
Когда выэто поврежденный объект, восстановите как можно больше полезных данных и двигайтесь дальше.
Результатом всегда будет хороший и действительный клон с максимально возможным количеством восстановленных данных и вы будете знаю точно, что вы выздоровели и что вы потеряли. Вы можете даже иметь коммиты, в которых некоторые файлы отсутствуют (потому что их внутренний объект BLOB-объекта был поврежден безвозвратно): вы можете сохранить заметку где-нибудь, возможно, используя git notes или, возможно, просто на бумаге, об этом и вернуться и восстановить то, что вы можетепозже, например.
Этот метод имеет тенденцию быть медленным и болезненным. Используемый вами метод - попытка восстановить поврежденный клон на месте - быстрее и проще, но может оставить вас с некоторыми скрытыми проблемами (например, потерянные коммиты, которые вы просто не помните, пришедшие после тот, который вы намеренно забили, потому что он был поврежден).