Как исправить ошибку GIT: объектный файл пуст?

Ответ 1

У меня была аналогичная проблема. У моего ноутбука закончилась батарея во время операции git. Бу.

У меня не было резервных копий. (N.B. Ubuntu One не является резервным решением для git, он поможет вам перезаписать ваш нормальный репозиторий с поврежденным.)

Для мастеров git, если это был плохой способ исправить, оставьте комментарий. Однако это помогло мне... хотя бы временно.

Шаг 1: Сделайте резервную копию .git(на самом деле я делаю это между каждым шагом, который что-то меняет, но с новым именем для копирования, например .git-old-1,.git-old-2, и т.д.):

cp -a .git .git-old

Шаг 2: Запустите git fsck --full

[email protected]:~/workspace/mcmc-chapter$ git fsck --full
error: object file .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e is empty
fatal: loose object 8b61d0135d3195966b443f6c73fb68466264c68e (stored in .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e) is corrupt

Шаг 3: Удалите пустой файл. Я понял, что это за черт; его пустота в любом случае.

[email protected]:~/workspace/mcmc-chapter$ rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e 
rm: remove write-protected regular empty file `.git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e'? y

Шаг 3: Запустите git fsck снова. Продолжайте удаление пустых файлов. Вы также можете cd в каталог .git и запустите find . -type f -empty -delete -print, чтобы удалить все пустые файлы. В конце концов git начал рассказывать мне, что он действительно что-то делал с каталогами объектов:

[email protected]:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: object file .git/objects/e0/cbccee33aea970f4887194047141f79a363636 is empty
fatal: loose object e0cbccee33aea970f4887194047141f79a363636 (stored in .git/objects/e0/cbccee33aea970f4887194047141f79a363636) is corrupt

Шаг 4: После удаления всех пустых файлов я в конечном итоге перешел на git fsck:

[email protected]:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: HEAD: invalid sha1 pointer af9fc0c5939eee40f6be2ed66381d74ec2be895f
error: refs/heads/master does not point to a valid object!
error: refs/heads/master.u1conflict does not point to a valid object!
error: 0e31469d372551bb2f51a186fa32795e39f94d5c: invalid sha1 pointer in cache-tree
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
missing blob 8b61d0135d3195966b443f6c73fb68466264c68e
missing blob e89896b1282fbae6cf046bf21b62dd275aaa32f4
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a
missing blob caab8e3d18f2b8c8947f79af7885cdeeeae192fd
missing blob e4cf65ddf80338d50ecd4abcf1caf1de3127c229

Шаг 5: Попробуйте git reflog. Сбой, потому что мой HEAD сломан.

[email protected]:~/workspace/mcmc-chapter$ git reflog
fatal: bad object HEAD

Шаг 6: Google. Найдите this. Вручную получите последние две строки reflog:

[email protected]:~/workspace/mcmc-chapter$ tail -n 2 .git/logs/refs/heads/master
f2d4c4868ec7719317a8fce9dc18c4f2e00ede04 9f0abf890b113a287e10d56b66dbab66adc1662d Nathan VanHoudnos <[email protected]> 1347306977 -0400  commit: up to p. 24, including correcting spelling of my name
9f0abf890b113a287e10d56b66dbab66adc1662d af9fc0c5939eee40f6be2ed66381d74ec2be895f Nathan VanHoudnos <[email protected]> 1347358589 -0400  commit: fixed up to page 28

Шаг 7: Обратите внимание, что с шага 6 мы узнали, что HEAD в настоящее время указывает на самую последнюю фиксацию. Поэтому попробуйте просто взглянуть на родительский коммит:

[email protected]:~/workspace/mcmc-chapter$ git show 9f0abf890b113a287e10d56b66dbab66adc1662d
commit 9f0abf890b113a287e10d56b66dbab66adc1662d
Author: Nathan VanHoudnos <[email protected]>
Date:   Mon Sep 10 15:56:17 2012 -0400

    up to p. 24, including correcting spelling of my name

diff --git a/tex/MCMC-in-IRT.tex b/tex/MCMC-in-IRT.tex
index 86e67a1..b860686 100644
--- a/tex/MCMC-in-IRT.tex
+++ b/tex/MCMC-in-IRT.tex

Это сработало!

Шаг 8: Теперь нам нужно указать HEAD на 9f0abf890b113a287e10d56b66dbab66adc1662d.

[email protected]:~/workspace/mcmc-chapter$ git update-ref HEAD 9f0abf890b113a287e10d56b66dbab66adc1662d

Что не жаловалось.

Шаг 9: Посмотрите, что говорит fsck:

[email protected]:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: refs/heads/master.u1conflict does not point to a valid object!
error: 0e31469d372551bb2f51a186fa32795e39f94d5c: invalid sha1 pointer in cache-tree
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
missing blob 8b61d0135d3195966b443f6c73fb68466264c68e
missing blob e89896b1282fbae6cf046bf21b62dd275aaa32f4
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a
missing blob caab8e3d18f2b8c8947f79af7885cdeeeae192fd
missing blob e4cf65ddf80338d50ecd4abcf1caf1de3127c229

Шаг 10: Недопустимый указатель sha1 в дереве кэша выглядел так, как будто он был из (теперь устаревшего) индексного файла (source). Поэтому я убил его и reset репо.

[email protected]:~/workspace/mcmc-chapter$ rm .git/index
[email protected]:~/workspace/mcmc-chapter$ git reset
Unstaged changes after reset:
M   tex/MCMC-in-IRT.tex
M   tex/recipe-example/build-example-plots.R
M   tex/recipe-example/build-failure-plots.R

Шаг 11: снова посмотрим на fsck...

[email protected]:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: refs/heads/master.u1conflict does not point to a valid object!
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a

свисающие капли не являются ошибками. Меня не интересует master.u1conflict, и теперь, когда он работает, я больше не хочу его трогать!

Шаг 12: Захват моих локальных изменений:

[email protected]:~/workspace/mcmc-chapter$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   tex/MCMC-in-IRT.tex
#   modified:   tex/recipe-example/build-example-plots.R
#   modified:   tex/recipe-example/build-failure-plots.R
#
< ... snip ... >
no changes added to commit (use "git add" and/or "git commit -a")


[email protected]:~/workspace/mcmc-chapter$ git commit -a -m "recovering from the git fiasco"
[master 7922876] recovering from the git fiasco
 3 files changed, 12 insertions(+), 94 deletions(-)

[email protected]:~/workspace/mcmc-chapter$ git add tex/sept2012_code/example-code-testing.R
[email protected]:~/workspace/mcmc-chapter$ git commit -a -m "adding in the example code"
[master 385c023] adding in the example code
 1 file changed, 331 insertions(+)
 create mode 100644 tex/sept2012_code/example-code-testing.R

Так что, надеюсь, это может пригодиться людям в будущем. Я рад, что это сработало.

Ответ 2

Объектные файлы git повреждены (как указано в других ответах). Это может произойти во время сбоев оборудования и т.д.

У меня было то же самое. Прочитав другие верные ответы, я нашел самый быстрый способ исправить сломанный репозиторий git со следующими командами (выполнить в рабочем каталоге git, который содержит папку .git):

(Обязательно сначала создайте резервную копию папки хранилища git!)

find .git/objects/ -type f -empty | xargs rm
git fetch -p
git fsck --full

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

PS. Этот ответ предполагает, что у вас есть удаленная копия вашего репозитория gitгде-то (например, в GitHub), а сломанный репозиторий - это локальный репозиторий, привязанный к удаленному репозиторию, который все еще находится в такте. Если это не так, тогда не пытайтесь исправить это, как я рекомендую.

Ответ 3

Я решил удалить несколько пустых файлов, которые обнаружил git fsck, а затем выполнил простой git pull.

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

Ответ 4

Эта ошибка происходит со мной, когда я нажимаю мой фиксатор, и мой компьютер зависает. Вот как я его исправил.

Шаги по исправлению

git status

показать пустой/поврежденный файл объекта

rm .git/objects/08/3834cb34d155e67a8930604d57d3d302d7ec12

удалите его

git status

Я получил сообщение fatal: bad object HEAD

rm .git/index

Я удаляю index для reset

git reset

фатальный: не удалось разобрать объект "HEAD".

git status
git pull

просто чтобы проверить, что происходит

tail -n 2 .git/logs/refs/heads/MY-CURRENT-BRANCH

печатает последние 2 строки tail -n 2 ветки журнала, чтобы показать мои последние 2 commit hash

git update-ref HEAD 7221fa02cb627470db163826da4265609aba47b2

Я выбираю последний commit hash

git status

показывает весь мой файл как deleted, потому что я удалил файл .git/index

git reset

продолжите reset

git status

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

Примечание. Этапы запускаются, когда я приземлился по этому вопросу и использовал ответы в качестве ссылки.

Ответ 5

У меня была такая же проблема: после вытаскивания удаленного репозитория, когда я получил статус git, я получил: "error: object file (...) пуст" "фатальный: потерянный объект (...) поврежден"

Как я решил это:

• git stash
• удалить файл git по ошибке (не уверен, что это необходимо)
• git stash clear

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

Ответ 6

Потому что мне приходится регулярно перезагружать свою виртуальную машину, поэтому почему-то эта проблема происходит со мной очень часто. После нескольких раз я понял, что не могу повторять процесс, описанный @Nathan-Vanhoudnos каждый раз, когда это происходит, хотя оно всегда работает. Затем я понял следующее более быстрое решение.

Шаг 1

Переместите все репо в другую папку.

mv current_repo temp_repo

Шаг 2

Повторное клонирование репо из источника.

git clone source_to_current_repo.git

Шаг 3

Удалите Все в новом репозитории, за исключением папки .git.

Шаг 4

Переместите Все из temp_repo в новую репо кроме папки .git.

Шаг 5

Удалите temp_repo, и мы закончили.

Через несколько раз я уверен, что вы можете сделать это очень быстро.

Ответ 7

• mv приложение для вашей папки, чтобы сделать резервную копию, т.е. mv app_folder app_folder_bk (это похоже на git stash)
• git clone your_repository
• Наконец,. Откройте инструмент слияния (я использую meld diff viewer linux или Winmerge Windows) и скопируйте изменения справа (app_folder_bk) влево (новая app_folder) (это похоже на git применяется прикладывание).

Это все. Возможно, это не лучший способ, но я думаю, что это так практично.

Ответ 8

В моем случае эта ошибка возникла из-за того, что я набрал сообщение фиксации, и мой ноутбук отключился.

Я сделал следующие шаги, чтобы исправить ошибку:

• git checkout -b backup-branch # Создать ветвь резервного копирования
• git reset --hard HEAD~4 # Reset для фиксации, где все работает хорошо. В моем случае мне пришлось отложить 4 фиксации в голове, то есть до тех пор, пока моя голова не окажется в этом пункте до того, как я наберу сообщение фиксации. Перед тем, как сделать этот шаг, скопируйте хэш коммитов, вы будете reset, в моем случае я скопировал хэш из 4 последних коммитов
• git cherry-pick <commit-hash> # Черри выбирают сброшенные фиксации (в моем случае 4, поэтому я сделал этот шаг 4 раза) из старой ветки в новую ветку.
• git push origin backup-branch # Нажмите новую ветку, чтобы убедиться, что все работает хорошо.
• git branch -D your-branch # Удалить ветвь локально ( "ваша ветвь" - это ветвь с проблемой)
• git push origin :your-branch # Удалить ветку с удаленного
• git branch -m backup-branch your-branch # Переименуйте ветвь резервного копирования, чтобы иметь имя ветки, у которой была проблема.
• git push origin your-branch # Нажмите новую ветку
• git push origin :backup-branch # Удалить ветку резервного копирования с удаленного устройства

Ответ 9

Вот простой и быстрый способ справиться с этой проблемой IF, у вас есть локальное репо со всеми веткими и требуется, и если вы в порядке с созданием нового репо ( или удаление серверного репо и создание нового в нем места):

• Создайте новое пустое репо на сервере (или удалите старое репо и создайте новое на своем месте)
• Измените удаленный URL-адрес вашей локальной копии, чтобы указать на удаленный URL-адрес нового репо.
• Нажимайте все ветки с вашего локального репо на новый серверный репо.

Это сохраняет все истории и ветки фиксации, которые у вас были в локальном репо.

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

Это решение работало для меня, когда я столкнулся с этой проблемой. У меня был один сотрудник. После того, как я переместил свое местное репо на новое дистанционное репо, он просто изменил свое местное репо, указав на URL удаленного репо, и все работает нормально.

Ответ 10

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

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

$ sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`

• 2>&1 перенаправляет сообщение об ошибке в stdout, чтобы иметь возможность grep
• Используемые опции grep:
  • -o возвращает только часть строки, которая фактически соответствует
  • -E включает расширенные регулярные выражения
  • -m 1 убедитесь, что возвращено только первое совпадение
  • [0-9a-f]{2} соответствует любому из символов между 0 и 9 и a и f, если два из них встречаются вместе
  • [0-9a-f]* соответствует любому числу символов между 0 и 9 и a и f вместе

Он по-прежнему удаляет только один файл за раз, поэтому вы можете вызвать его в цикле, например:

$ while true; do sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`; done

Проблема с этим заключается в том, что он больше не выводит ничего полезного, поэтому вы не знаете, когда он будет завершен (он не должен делать ничего полезного через некоторое время)

Чтобы "исправить" это, я просто добавил вызов git fsck --full после каждого раунда: $ while true; do sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`; git fsck --full; done

Теперь он примерно в два раза быстрее, но он выводит его "состояние".

После этого я играл вокруг некоторых с предложениями в этой теме и, наконец, дошел до точки, где мог git stash и git stash drop много сломанного материала.

первая проблема решена

Впоследствии у меня все еще была следующая проблема: unable to resolve reference 'refs/remotes/origin/$branch': reference broken, который можно было бы решить $ rm \repo.git\refs\remotes\origin\$branch

$ git fetch

Затем я сделал $ git gc --prune=now

$ git remote prune origin

для хорошей меры и

git reflog expire --stale-fix --all

чтобы избавиться от error: HEAD: invalid reflog entry $blubb при запуске git fsck --full.

Ответ 11

Скопируйте все (в папку, содержащую .git), в резервную копию, затем удалите все и перезапустите. Убедитесь, что у вас есть git remote handy:

git remote -v
 origin [email protected]:rwldrn/idiomatic.js.git (fetch)
 origin [email protected]:rwldrn/idiomatic.js.git (push)

Тогда

mkdir mygitfolder.backup
cp mygitfolder/* mygitfolder.backup/
cd mygitfolder
rm -r * .git*
git init
git remote add origin [email protected]:rwldrn/idiomatic.js.git

Затем объедините все новые файлы вручную и попробуйте включить компьютер.

Ответ 12

Была такая же проблема после проверки мастера из чистой ветки. Через некоторое время я узнал много модифицированных файлов в главном. Я не знаю, почему они были там, после перехода с чистой ветки. В любом случае, потому что измененные файлы не имели для меня никакого смысла, я просто спрятал их, и ошибка исчезла.

git:(master) git stash

Ответ 13

Решение на двенадцать шагов, рассмотренное выше, помогло мне избавиться от пробки. Благодарю. Ключевыми шагами должны были войти: git fsck --full

и удалить все пустые объекты

rm.git/objects/...

Затем, получив две строки:  tail -n 2.git/logs/refs/heads/master

С возвращенными значениями

git update-ref HEAD...

В этот момент у меня не было больше ошибок, поэтому я сделал резервную копию моих последних файлов. Затем выполните растягивание git, а затем нажмите git. Скопировал мои резервные копии в файл репозитория git и сделал еще один git push. Это вызвало у меня настоящее.

Ответ 14

если у вас есть резервная копия OLD и вы спешите:

создайте NEW BACKUP текущего, git -прорываемого пути к проекту.

1 - переместите .git в корзину (никогда не удаляйте)
2 - скопируйте .git из резервной копии OLD
3 - git pull (создаст конфликты слияния)
4 - переместите все источники (все, что вы помещаете в git) в корзину: ./src (никогда не удаляйте)
5 -.copy все ваши источники (все, что вы помещаете в git) из NEW BACKUP
6 - принять все "слияния" на git gui, нажать и... хлопнуть руками!

Ответ 15

Отпусти простую.. только в случае, если вы загрузили источник на удаленный git репо.

• Резервное копирование .git
• проверьте git
  • git fsck --full
• удалить пустой файл объекта (все)
  • rm.git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e
• снова проверьте ваш git.
  • git fsck --full
• извлеките источник из удаленного устройства git
  • git мастер создания тяги

Ответ 16

зафиксируйте свои изменения (если они есть), а затем просто git reset --hard

Ответ 17

Если вам не нужны ваши исторические фиксации, просто запустите

rm -r.git

Затем ответьте да на что-нибудь, спрашивая об удалении файлов, защищенных от записи. Проблема решена через минуту.