Восстановить поврежденный репозиторий git

Мой репозиторий git поврежден после нескольких жестких перезагрузок из-за проблем с электропитанием, и теперь я не могу его исправить (я был в середине постановки некоторых файлов при последнем сбое питания)

$ git status                                                                                                                          
fatal: failed to read object 3d18855708b0f127d40c13c679559d7679228b69: Invalid argument
$ git fsck
fatal: failed to read object 24377c609184c192f3f3c1733bac7115c1080758: Invalid argument
$ git branch -a
(...works, lists branches...)
$ git checkout someotherbranch
fatal: failed to read object 3d18855708b0f127d40c13c679559d7679228b69: Invalid argument
$ git log                                              
fatal: failed to read object 3d18855708b0f127d40c13c679559d7679228b69: Invalid argument
$ git log someotherbranch
(...works, shows commits...)

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

Ответ 1

Мое решение для аналогичной ситуации заключалось в замене хэша поврежденного объекта в .git/refs/heads/my-working-branch на хэш предыдущего фиксации (который можно найти в .git/logs/HEAD).

Ответ 2

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

Ответ 3

Для меня я включил TRIM в OSX с не-Apple SSD (что не рекомендуется) и, по-видимому, вызвало различные сбои на моем загрузочном диске. Таким образом, коррумпированная фиксация была глубокой в истории.

Мне не все равно, что я ремонтирую свое репо, но у меня есть несколько локальных ветвей, которые были слишком экспериментальными, чтобы беспокоиться о том, чтобы перейти к удаленному репо, и я хотел бы спасти работу в этих ветвях.

Теоретически, поскольку это локальное репо, я чувствую, что git должен иметь возможность восстанавливать/восстанавливать себя с использованием источника. Почему это невозможно?

Во всяком случае, я наткнулся на эту классную стратегию, чтобы направить ветку на другой локальный репозиторий git. К сожалению, клонирование репо в ../repo_copy, а затем использование что в качестве локального пульта произошла ошибка:

! git push --force local_remote HEAD
fatal: failed to read object e0a9dffddeeca96dbaa275636f8e8f5d4866e0ed: Invalid argument
error: failed to push some refs to '/Users/steve/Dev/repo_copy'

Итак, я начал с пустого репо, а нажатие ветвей на него работало нормально. Поэтому для любой локальной ветки, у которой git log не заканчивалось:

....
    Fixing cukes
fatal: failed to read object e0a9dffddeeca96dbaa275636f8e8f5d4866e0ed: Invalid argument

Я просто проверил бы это, а затем сделаю git push --force local_remote HEAD. Последнее, что я сделал, это:

! cd ~/Dev/repo_copy
! git remote add origin [email protected]:sdhull/my_repo.git  # real remote

Затем я вошел в git config -e и установил свою главную ветку и вернулся и проиграл! Дайте мне знать в комментариях, если вы хотите получить более подробную информацию об этом подходе. Ура!

Ответ 4

Попробуйте сделать резервную копию репозитория, а затем запустите git reset --hard [email protected]{1}, чтобы вернуться к предыдущему HEAD и посмотреть, работает ли это. Это может быть только текущий HEAD, который поврежден.

(Вы также должны запустить fsck на своем диске, если вы еще этого не сделали.)

Ответ 5

Мне удалось восстановить свое репо:

zsh(broken)% git log master
error: object file .git/objects/7f/cab8648a989d9bb3f5246e6be7220395493395 is empty
error: object file .git/objects/7f/cab8648a989d9bb3f5246e6be7220395493395 is empty
fatal: loose object 7fcab8648a989d9bb3f5246e6be7220395493395 (stored in .git/objects/7f/cab8648a989d9bb3f5246e6be7220395493395) is corrupt
zsh(broken)% cat .git/refs/heads/master
7fcab8648a989d9bb3f5246e6be7220395493395
e311726c4eb970f4d4f504ad86248d322855018f da9c14d03e4849394087b61ff6272399937f7cce Nikolay Orliuk <[email protected]> 1379583764 +0300   commit: plan: timings

Сбрасывая master в pre commit da9c14d03e4849394087b61ff6272399937f7cce, как описано @Nash Bridges:

zsh(broken)% echo da9c14d03e4849394087b61ff6272399937f7cce > .git/refs/heads/master
zsh(broken)% git log --oneline -1 master
da9c14d plan: timings
zsh(broken)% git fsck
Checking object directories: 100% (256/256), done.
error: object file .git/objects/0e/ace931fdc851da254e9522596d1517d0ed51c5 is empty
error: object file .git/objects/0e/ace931fdc851da254e9522596d1517d0ed51c5 is empty
fatal: loose object 0eace931fdc851da254e9522596d1517d0ed51c5 (stored in .git/objects/0e/ace931fdc851da254e9522596d1517d0ed51c5) is corrupt

Создание нового пустого репо, извлечение master из сломанного

zsh(broken)% mkdir ../recover && cd ../recover && git init
Initialized empty Git repository in /home/nikolay/talks/y/recover/.git/
zsh(recover)% git fetch ../broken master
remote: Counting objects: 44, done.
remote: Compressing objects: 100% (44/44), done.
remote: Total 44 (delta 20), reused 0 (delta 0)
Unpacking objects: 100% (44/44), done.
From ../broken
 * branch            master     -> FETCH_HEAD
zsh(recover)% git reset --hard FETCH_HEAD
HEAD is now at da9c14d plan: timings
zsh% git fsck
Checking object directories: 100% (256/256), done.

Чтобы восстановить те изменения, которые были на пути к master:

zsh(recover)% rm -rf * && cp -a ../broken/* ./          
zsh(recover)% git add -u && git commit -m 'prepare for publishing'

Ответ 6

Я выполнил следующие инструкции: здесь

$ cd /tmp/
$ git clone good-host:/path/to/good-repo
$ cd /home/user/broken-repo
$ echo /tmp/good-repo/.git/objects/ > .git/objects/info/alternates
$ git repack -a -d
$ rm -rf /tmp/good-repo

Работал для меня

Ответ 7

Самое простое решение для меня: вы могли бы git клонировать в новой папке, а затем заменить чистую новую_панель/.git на старую папку (сломанную папку). Это хорошо работает для меня!

git clone ...(remote) new_folder
mv old_folder/.git  old_folder/.git_old
cp -R new_folder/.git  old_folder/

Ура!

Ответ 8

Другая альтернатива, которая работала для меня, заключалась в reset головке и индексе git в предыдущем состоянии, используя:

git reset --keep

Я также пробовал следующие команды, но они не работали для меня, но они могли бы для вас:

git reset --mixed git fsck --full git gc --auto git prune --expire now git reflog --all