Ответ 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, которую они должны были исправить.