Как восстановить поврежденный объект в репозитории git (для новичков)?

Я попытался открыть мой репозиторий сегодня, и в нем не было никакой истории фиксации. Все, что я пробовал (git статус, git log, git checkout...), выдает ошибку о поврежденном объекте.

Я исследовал эту проблему в Интернете и нашел статью Линуса Торвальдса, но потерялся в точке, где он нашел недействительный идентификатор ссылки: ни один из моих идентификаторов файлов, дерева или blob, не соответствует идентификатору вины, выдаваемому сообщением об ошибке.

Затем я вернулся к статье о восстановлении "git объектов, поврежденных сбой жесткого диска" и (после перемещения объекта преступника с пути) работал мой до тех пор, пока

$ cat packed-refs

в этот момент мой компьютер сказал: cat: packed-refs: No such file or directory Я пропустил этот шаг и сделал

$ git fsck --full

и получил соответствующий вывод, но затем я должен был скопировать виновника (или то, что я называл виновником, идентификатор sha1, сброшенным ошибкой) из резервного хранилища обратно в основной репозиторий, а затем скопировать насколько я могу судить, отсутствующие объекты из резервного хранилища в основной репозиторий; и я не хочу делать что-либо слишком резкое, или я могу заставить что-то, что я не могу принести позже.

Итак, мой вопрос есть (есть), я должен был сделать резервную копию (ooh, newbie alert), или это было, когда я распаковал файл .pack? И "виновник" я копирую обратно на самом деле чистый файл, т.е. Не поврежден?

(Я думаю, справедливо сказать, что меня изначально путал простой штрих в файле Torvalds между "git" и "fsck". Поэтому я ДЕЙСТВИТЕЛЬНО новичок в этом.)

BUG-LIST

Исходная ошибка:

$ git status
fatal: object 016660b7605cfc2da85f631bbe809f7cb7962608 is corrupted

Ошибка при перемещении поврежденного объекта:

$ git status
fatal: bad object HEAD
$ git fsck --full
error: HEAD: invalid sha1 pointer 016660b7605cfc2da85f631bbe809f7cb7962608
error: refs/heads/RPG does not point to a valid object!
dangling tree 2c1033501b82e301d47dbf53ba0a199003af25a8
dangling blob 531aca5783033131441ac7e132789cfcad82d06d
dangling blob 74a47ff40a8c5149a8701c2f4b29bba408fa36f5
dangling blob b8df4d9751c0518c3560e650b21a182ea6d7bd5e
dangling blob fc2d15aead4bd0c197604a9f9822d265bb986d8b

$ git ls-tree 2c1033501b82e301d47dbf53ba0a199003af25a8
040000 tree 4a8b0b3747450085b1cd920c22ec82c18d9311bd    folder1
040000 tree 33298295f646e8b378299191ce20b4594f5eb625    folder2
040000 tree dec82bad6283fc7fcc869c20fdea9f8588a2f1b2    folder3
040000 tree 4544967c6b04190f4c95b516ba8a86cab266a872    folder4

$ git ls-tree dec82bad6283fc7fcc869c20fdea9f8588a2f1b2
100644 blob 67bda6df733f6cd76fc0fc4c8a6132d8015591d8    fileA
100644 blob 4cb7272c9e268bfbd83a04e568d7edd87f78589c    fileB
100644 blob ce9e0f2cc4d3b656fa30340afbdfed47fe35f3ef    fileC

$ git ls-tree 4544967c6b04190f4c95b516ba8a86cab266a872
100644 blob d64fe3add8328d81b1f31c9dbd528956ab391fb6    fileD
100644 blob d1ebd7df7082abc5190d87caa821bf3edb7b68e8    fileE
100644 blob bb6cd264e47a3e5bc7beadf35ea13bac86024b02    ...
100644 blob 995d622b9012f4ef69921091d1e1a73f32aa94e6
100644 blob 9141dbd2b1c7931a6461195934b6599f5dfb485a 
100644 blob ab128da1d82907cd0568448dc089a7996d5f79d3
100644 blob 57b11a7eb408a79739d2bb60a0dc35c591340d18
100644 blob 118105291c1c6ca4a01744889ffafbb018bc7ed3
100644 blob 86b1dfda56d0603f16910228327751f869d16bdc
100644 blob 077fe0cddde0d0be9d0974f928f66815caca7b76
100644 blob c0b32fd0450f21994bdc53ea83d3cf0bccd74004
100644 blob 37b87a4d11453468c4ae04572db5d322cd2d1d80
100644 blob 79d39f8d4e57fa3a71664598a63b6dfd88149638
100644 blob ee07bbe3e8cb5d6bb79fb0cd52cfbc9bd830498d    files

$ git ls-tree 33298295f646e8b378299191ce20b4594f5eb625
100644 blob f9d6f45cd028aec97f761f00c5f4f2f6b50fb925    MoreFiles
100644 blob 0cb9eed1d0dd9214d54a03af1bda21f37b8c0d02
100644 blob 198e4f97ece735cce47b7e99b54f1b5fa99fabf5
100644 blob fc004212fa8e483e5a8ab35b508027c7a9a1cbfa
100644 blob 0c7d74c7a9a8337b4a9f20802b63d71d42287f89

$ git ls-tree 4a8b0b3747450085b1cd920c22ec82c18d9311bd
100644 blob 0320f5b23dd7cce677fac60b9ad03f418cff5c88    oneLASTfile

После перемещения поврежденного объекта назад:

$ git log --raw --all
fatal: object 016660b7605cfc2da85f631bbe809f7cb7962608 is corrupted

$ cat packed-refs
cat: packed-refs: No such file or directory

$ git fsck --full
fatal: object 016660b7605cfc2da85f631bbe809f7cb7962608 is corrupted

После перемещения файла обратно:

$ git fsck --full`  
error: HEAD: invalid sha1 pointer 016660b7605cfc2da85f631bbe809f7cb7962608
error: refs/heads/RPG does not point to a valid object!
dangling tree 2c1033501b82e301d47dbf53ba0a199003af25a8
dangling blob 531aca5783033131441ac7e132789cfcad82d06d
dangling blob 74a47ff40a8c5149a8701c2f4b29bba408fa36f5
dangling blob b8df4d9751c0518c3560e650b21a182ea6d7bd5e
dangling blob fc2d15aead4bd0c197604a9f9822d265bb986d8b

После распаковки файла .pack:

$ git log
fatal: bad object HEAD

$ cat packed-refs
cat: packed-refs: No such file or directory

$ git fsck --full
error: HEAD: invalid sha1 pointer 016660b7605cfc2da85f631bbe809f7cb7962608
error: refs/heads/RPG does not point to a valid object!
dangling tree 2c1033501b82e301d47dbf53ba0a199003af25a8
dangling blob 531aca5783033131441ac7e132789cfcad82d06d
dangling blob 74a47ff40a8c5149a8701c2f4b29bba408fa36f5
dangling blob b8df4d9751c0518c3560e650b21a182ea6d7bd5e
dangling blob fc2d15aead4bd0c197604a9f9822d265bb986d8b

Ответ 1

Хорошо, так. Из второго сообщения об ошибке видно, что поврежденный объект, который вы перенесли, был фиксацией. (ГОЛОВА указывала на это!) К сожалению, это означает, что трудно вручную его восстановить. (К сожалению, это невозможно, если вы не можете точно помнить, что такое сообщение фиксации и какое время вы совершили коммит.) К счастью, это означает, что легко воскресить новую фиксацию с тем же содержимым файла - вы будете просто нужно написать для него новое сообщение.

Прежде чем начать, просмотрите содержимое .git/HEAD - если это имя ветки, помните, что для более позднего.

Во-первых, нам нужно выяснить, что должен был родитель этого коммита. Вы можете использовать git reflog, чтобы посмотреть заголовок HEAD, и найти SHA1, где HEAD был только что вы сделали commit 016660b. Он должен выглядеть примерно так:

016660b [email protected]{n}: commit: <subject of commit>
1234abc [email protected]{n-1}: ...

Вы можете скопировать SHA1 предыдущей позиции HEAD и проверить, что commit:

git checkout 1234abc

Затем вы можете прочитать в дереве, что ваша поврежденная фиксация имела:

git read-tree 2c1033501b82e301d47dbf53ba0a199003af25a8

И затем зафиксируйте!

git commit

Теперь у вас есть вопрос о том, что должно было произойти с вашими веткими. Если HEAD указывал на ветку (скажем, мастер), которая, в свою очередь, указывала на поврежденную фиксацию, мы определенно хотим исправить это:

git branch -d master       # remove the original master branch
git checkout -b master     # recreate it here

Если есть другие ветки, в которых содержится поврежденная фиксация, вам также нужно будет немного восстановить их - сообщите мне, нужна ли вам помощь.

Ответ 2

FWIW, вот ответ, который более практичен, чем много безнадежно оптимистичных по другим вопросам о поврежденных репозиториях git, большинство из которых делают необоснованное предположение о том, что плохой OP может "просто повторно клонировать с удаленного происхождение! Хм. Но. Подожди секунду. Что, если я источник?

Ужас

История начинается, когда попытка запустить простой git gc --aggressive показала, что, без ведома для меня, в какой-то момент моя полностью локальная ретрансляция git каким-то образом получила полный халат: он не смог зарегистрировать ничего за пределами нескольких месяцев назад, тем самым потеряв большую часть своей истории, и кричал gutturally всякий раз, когда его просили git fsck --full | grep -v dangling. Несколько объектов были идентифицированы как потерянные на git fsck.

git-repair: минимизация ужасающего ручного труда с 2014 года

После паники и поиска много вопросов с чрезмерно проголосовавшими плохими ответами, просто говоря "просто повторить клонирование из удаленного источника!" - что, позвольте мне выразить суть, у меня нет, потому что я источник - я нашел git-repair, сделал простой sudo aptitude install git-repair, и пусть он выполнит все утомительные автоматические исправления, которые, вероятно, заняли бы у меня часы (пожалуйста: запустите копию поврежденного репо [duh], без --force!)

Это помогло уменьшить количество ужасов, сообщенных git fsck --full | grep -v dangling. Но события за середину августа все еще недостижимы.

В частности, все это, казалось, было сосредоточено вокруг одного коммита, которого невозможно было получить. Как я мог его восстановить? Поиск не очень помог!

У вас есть резервная копия, правильно?

Здесь, где мне посчастливилось иметь резервную копию с конца ноября. Вы берете резервные копии, не так ли? В моем случае это была ручная zip-репо (моя ежедневная программа резервного копирования - это какая-то ужасная инкрементная вещь tar, которую я никогда не тестировал... a-cough)... но, пожалуйста, это было достаточно хорошо. Он не пострадал, как бы то ни было, что унизило мое живое репо.

Но отсутствующий объект, похоже, просто не хранился в этой резервной копии .git/objects/XY/RESTOFHASHBLAHBLAHBLAH. Вероятно, это был коммит, а не файл. Я не знаю! git - это волшебство для меня, навсегда превосходящее мою способность осмысливать. Я просто нуждался в исправлении, быстро. Не потому, что мы все здесь?

Восстановить объекты из резервной копии (что у вас есть, правда?)

С резервным копированием теперь в руке у меня была довольно глупая идея: "Нет, это не может работать!", и сразу же обнаружил, что просто наивно работает cp -fr /path/to/repo_backup/.git/objects/* /path/to/repo_git-repaired/.git/objects до с файлом слияние каталога .git/objects резервное копирование в свою копию в моем поврежденном, частично восстановленном репо... работало, чтобы восстановить всю историю - вернемся к хорошему ol initial commit lol. Доказательство исправления: git fsck --full тоже был счастлив (несмотря на все оборванные бит).

Затем я взял резервные копии живых/поврежденных, частично отремонтированных и, казалось бы, восстановленных репозиториев на отдельный диск, в случае, если мне понадобится их снова.

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

Бесконечные оговорки в бесконечных комбинациях

Теперь, очевидно, все это связано с предостережениями: вы должны попробовать все на копии вашего поврежденного репо, прочитать всю документацию, подумать о том, чтобы быть немного более осторожным, чем я был (что принудительно cp), и не держите меня ответственным или ответственным за абсолютно все, что пойдет не так *... но это дает вам что-то лучшее, чтобы попытаться, чем "просто повторить клонирование из удаленного источника!", правильно?

* Если, однако, все идет правильно, может быть сделано большое пожертвование.;)

Если кто-то нуждается во мне, я буду подозрительно смотреть в общем направлении на моем диске, надеюсь, придумает подпрограмму резервного копирования, которая не потребует двухзначных часов для восстановления (если вообще), и, возможно, даже немного поспав.

Ответ 3

У меня была та же проблема. Однако моя проблема была решена с изменением разрешений папок и подпапок .git/objects (рекурсивно) на сервере. Что-то вроде:

chmod -R 770 .git/objects

Я думаю, что это не ваша проблема, но в моем случае это было разрешено.