Коррупция Github Repo - Sha1 Collision

Вчера одна из моих командных проверок испортила наш реестр github. На github они отображали эту ошибку:

$ git fsck
error: sha1 mismatch 87859f196ec9266badac7b2b03e3397e398cdb18

error: 87859f196ec9266badac7b2b03e3397e398cdb18: object corrupt or missing
missing blob 87859f196ec9266badac7b2b03e3397e398cdb18

Когда я попытался вытащить другую машину, я получил следующее:

Hyperion:Convoy-clone saalon$ git fsck
warning in tree 5b7ff7b4ac7039c56e04fc91d0bf1ce5f6b80a67: contains zero-padded file modes
warning in tree 5db54a0cdcd5775c09365c19c061aff729579209: contains zero-padded file modes
broken link from    tree 6697c12387f8909cfe7250e9d5854fd6713d25c1
              to    blob 87859f196ec9266badac7b2b03e3397e398cdb18
dangling tree 144becf61ae14cec34b6af1bd8a0cf4f00d346d1
missing blob 87859f196ec9266badac7b2b03e3397e398cdb18

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

Я отследил blob к конкретному файлу, что проблема, но после прохождения процесса Git FAQ по исправлению ошибки с неправильной ссылкой мне не повезло.

Я просмотрел документацию Github и нашел процесс удаления мастер-репо из github и перезагрузки с оскорбительной машины. Я пробовал это, но когда я пошел, чтобы повторно нажать главную ветвь, я получил следующую ошибку:

fatal: SHA1 COLLISION FOUND WITH 87859f196ec9266badac7b2b03e3397e398cdb18 !
error: unpack failed: index-pack abnormal exit

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

Ответ 1

После некоторых проблем с GitHub (и некоторой помощи по устранению неполадок ssmir) эта проблема разделяется между тем, что мне нужно было решить, и тем, что нужно решить Гитубу.

То, что нужно было решить на моем конце, было следующим:

Hyperion:Convoy-clone saalon$ git fsck
warning in tree 5b7ff7b4ac7039c56e04fc91d0bf1ce5f6b80a67: contains zero-padded file modes
warning in tree 5db54a0cdcd5775c09365c19c061aff729579209: contains zero-padded file modes
broken link from    tree 6697c12387f8909cfe7250e9d5854fd6713d25c1
              to    blob 87859f196ec9266badac7b2b03e3397e398cdb18
dangling tree 144becf61ae14cec34b6af1bd8a0cf4f00d346d1
missing blob 87859f196ec9266badac7b2b03e3397e398cdb18

Если вы заметили, есть неработающая ссылка с дерева на blob. Это говорит о том, что есть папка, в которой должен быть файл, но на самом деле нет файла. Кто-то добавил файл к своему местному репо и нажал его, но сам файл не попал в удаленное репо. Теперь каждый раз, когда кто-то сам сбрасывает репо, они получают ту же самую сломанную ссылку файловой системы git.

Инструкции здесь дают хорошую работу, объясняя, что делать, если у вас есть проблема, но в разгар фактического кризиса я нашел описание немного недостающим в контексте. Он дал четкий список шагов, но не очень хорошая идея о том, почему, по крайней мере, не для тех, кто еще немного знаком с Git.

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

Итак, сначала нам нужно выяснить, какие blobs/files находятся в этом дереве. Для этого вы используете git ls-tree.

git ls-tree 6697c12387f8909cfe7250e9d5854fd6713d25c1

В моем случае указан только один файл: файл, который был поврежден. В вашем случае это может привести к полному списку файлов, и в этом случае вам нужно будет совместить хеш-память SHOB1 с блоком/файлом с указанным в ошибке с ошибкой. В моем случае это было так:

100644 blob 87859f196ec9266badac7b2b03e3397e398cdb18    short_description.html

Обратите внимание, что это не дает вам каталог, в котором фактически должен находиться файл. Такое разочарование, но с небольшой детективной работой вы можете его найти. Файл может быть уникально назван, и в этом случае вы можете просто найти find для имени файла. Или вы можете просмотреть историю фиксации и посмотреть, когда и где был помещен файл short_description.html.

Здесь часть GitFaq была не совсем понятна. Говорят, чтобы заново создать файл, затем запустите эту команду:

git hash-object -w db/content/page_parts/venues/86/short_description.html

Но что это значит?

В принципе, при запуске git хэш-объект возвращает хэш файл sha1 для этого файла. И (и здесь важная часть) он создает blob из файла, а blob - это то, чего нам не хватало. Здесь часть, на которой это не понятно, хотя: Чтобы это работало, файл должен точно соответствовать файлу, изначально вызвавшему проблему. Другими словами, если в этом файле short_description.html содержался контент, вы не можете просто создать пустой файл и запустить хэш-объект. Если вы это сделаете, хэш-код blob sha1 не будет соответствовать отсутствию git, и эта сломанная ссылка будет по-прежнему нарушена.

Вот почему вам нужно быть в режиме репинга. У всех остальных есть ссылка, но не файл и нет blob. Обижающая машина (надеюсь) все еще имеет исходный файл. В моем случае у них не было оригинального файла (в моем перевороте, он был удален непреднамеренно), но когда я посмотрел на их историю фиксации на своем поле, diff содержал содержимое файла, который был совершен, но никогда превратил его в github. Я скопировал это, воссоздал файл и запустил хэш-объект. В следующий раз, когда я запустил git fsck, сломанная ссылка исчезла.

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

Что касается проблемы столкновения SHA1, которую я получил, когда попытался нажать на github? Эта уродливая присоска?

fatal: SHA1 COLLISION FOUND WITH 87859f196ec9266badac7b2b03e3397e398cdb18 !
error: unpack failed: index-pack abnormal exit

Это была проблема на стороне github, которую они должны были исправить.

Ответ 2

Просто напоминание. Небольшая вероятность того, что что-то происходит, - это не то же самое, что она не может произойти. Вы можете получить хеш-коллизии с помощью git использования sha-1. Когда у вас есть два файла, которые сталкиваются, вероятность становится 100%. В этот момент тонкое утешение от теоретической вероятности. Добавьте пространство к одному, и все будет хорошо.

Ответ 3

Я столкнулся с той же проблемой и побежал:

git prune  
git gc

в котором упоминалось

error: плохой ref для refs/remotes/origin/ticketName

поэтому я удалил ссылку и исправил проблему:

rm .git/refs/remotes/origin/ticketName