После некоторого перерыва с GitHub (и некоторой справки по устранению неполадок от ssmir) эта проблема разделена между тем, что мне нужно было решить, и тем, что нужно решить Github.
Что нужно было решить с моей стороны, так это:
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
Если вы заметили, существует неработающая связь дерева с блобом. Это говорит о том, что есть папка, в которой должен быть файл, но на самом деле в ней нет файла. Кто-то добавил файл в локальное хранилище и выдвинул его, но сам файл не попал в удаленное хранилище. Теперь каждый раз, когда кто-то самостоятельно закрывает репозиторий, он получает одну и ту же битую ссылку на файловую систему git.
Инструкции здесь хорошо объясняют, что делать, если у вас возникла проблема, но в разгар реального кризиса я обнаружил, что описание немного не хватает контекста. Он дал четкий список шагов, но не очень хорошо представлял причину - по крайней мере, не для того, кто еще немного новичок в Git.
По сути, вам нужно выяснить, что это за файл, отсутствующий большой двоичный объект, отследить, какой компьютер проверял его в последний раз, и приступить к работе с локальным репозиторием. Их компьютер имеет как ссылку SHA1 на файл , так и содержимое самого файла. У всех остальных куча сломанных.
Итак, во-первых, нам нужно выяснить, какие капли / файлы находятся в этом дереве. Для этого вы используете git ls-tree.
git ls-tree 6697c12387f8909cfe7250e9d5854fd6713d25c1
В моем случае это был только один файл: файл, который был поврежден. В вашем случае это может привести к полному списку файлов, и в этом случае вам нужно сопоставить SHA1-хэш блоба / файла с тем, который указан в ошибке неработающей ссылки. В моем случае это было так:
100644 blob 87859f196ec9266badac7b2b03e3397e398cdb18 short_description.html
Обратите внимание, что он не дает вам каталог, в котором файл должен находиться. Это немного расстраивает, но с небольшой детективной работой вы можете его найти. Файл может иметь уникальное имя, и в этом случае вы можете просто найти имя файла. Или вы можете просмотреть свою историю коммитов и посмотреть, когда и где был размещен файл с именем short_description.html.
Вот та часть, в которой GitFaq был не совсем понятен. Они говорят, чтобы восстановить файл, а затем выполнить эту команду:
git hash-object -w db/content/page_parts/venues/86/short_description.html
Но что это делает?
Обычно, когда вы запускаете git hash-object возвращает хэш sha1 для этого файла. И (и вот важная часть) он создает блоб из файла, а блоб был тем, чего нам не хватало. Вот часть, над которой неясно, однако: для того, чтобы это работало, файл должен точно соответствовать файлу, который изначально вызвал проблему. Другими словами, если в этом файле short_description.html есть содержимое, вы не можете просто создать пустой файл и запустить hash-объект. Если вы это сделаете, хэш блоба sha1 не будет соответствовать отсутствующему git, и эта битая ссылка все равно будет сломана.
Вот почему вы должны быть в репо нарушителя. У всех есть ссылка, но нет файла и блоба. У компьютера-нарушителя (надеюсь) все еще есть оригинальный файл. В моем случае у них не было исходного файла (в моем случае, он был случайно удален), но когда я посмотрел на историю их коммитов на их коробке, diff содержал содержимое файла, который был зафиксирован, но никогда сделал это на github. Я скопировал это, пересоздал файл и запустил hash-объект. В следующий раз, когда я запустил git fsck, битая ссылка исчезла.
Одно примечание: технически эта проблема может быть исправлена в чьем-либо репо, при условии, что вы можете восстановить отсутствующий файл. В моем случае я действительно создал файл на компьютере-нарушителе, но отправил его мне по электронной почте и устранил проблему в чистом хранилище в другой системе. Важно точно воссоздать файл, чтобы он генерировал тот же хэш sha1, который отсутствует в репо.
Что касается проблемы столкновения SHA1, которую я получил, когда пытался нажать на github? Это уродливая присоска?
fatal: SHA1 COLLISION FOUND WITH 87859f196ec9266badac7b2b03e3397e398cdb18 !
error: unpack failed: index-pack abnormal exit
Это была проблема на стороне github, которую они должны были исправить.