Когда я пытаюсь зафиксировать изменения, я получаю эту ошибку:
error: object file .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0 is empty
fatal: loose object 3165329bb680e30595f242b7c4d8406ca63eeab0 (stored in .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0) is corrupt
Есть идеи, как решить эту ошибку?
РЕДАКТИРОВАТЬ
Я пытался git fsck
у меня есть:
error: object file .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71 is empty
fatal: loose object 03dfd60a4809a3ba7023cbf098eb322d08630b71 (stored in .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71) is corrupt
git add
операцию? Ваш жесткий диск заполнен?git fsck
позаботились об этом.Ответы:
У меня была аналогичная проблема. В моем ноутбуке разрядился аккумулятор во время операции git. Бу.
У меня не было никаких резервных копий. (NB Ubuntu One не является решением для резервного копирования для git; он будет перезаписывать ваш нормальный репозиторий вашим поврежденным.)
Для мастеров мерзавцев, если это был плохой способ исправить это, пожалуйста, оставьте комментарий. Это, однако, сработало для меня ... по крайней мере, временно.
Шаг 1: Сделайте резервную копию .git (фактически я делаю это между каждым шагом, который что-то меняет, но с новым именем для копирования, например .git-old-1, .git-old-2 и т. Д.) :
Шаг 2: Запустить
git fsck --full
Шаг 3: Удалить пустой файл. Я понял, какого черта; все равно пусто
Шаг 3: Запустите
git fsck
снова. Продолжить удаление пустых файлов. Вы также можетеcd
в.git
каталог и запустить,find . -type f -empty -delete -print
чтобы удалить все пустые файлы. В конце концов, git начал говорить мне, что он что-то делает с каталогами объектов:Шаг 4: После удаления всех пустых файлов я в конечном итоге приступил к
git fsck
работе:Шаг 5: попробуй
git reflog
. Сбой, потому что моя голова сломана.Шаг 6: Google. Найди это . Вручную получите две последние строки reflog:
Шаг 7: Обратите внимание, что из шага 6 мы узнали, что HEAD в данный момент указывает на самый последний коммит. Итак, давайте попробуем просто взглянуть на родительский коммит:
Это сработало!
Шаг 8: Теперь нам нужно указать HEAD 9f0abf890b113a287e10d56b66dbab66adc1662d.
Который не жаловался.
Шаг 9: Посмотрите, что говорит fsck:
Шаг 10. Недопустимый указатель sha1 в дереве кеша выглядел так, как будто он был из (теперь устаревшего) индексного файла ( источника ). Поэтому я убил его и сбросил репо.
Шаг 11: Снова посмотрим на fsck ...
В свисающие сгустки не являются ошибками . Я не имею отношения к master.u1conflict, и теперь, когда он работает, я не хочу больше его трогать!
Шаг 12: Догоняю с моими местными правками:
Надеюсь, что это может пригодиться людям в будущем. Я рад, что это сработало.
источник
Объектные файлы git повреждены (как указано в других ответах). Это может произойти во время поломок машины и т. Д.
У меня было то же самое. Прочитав остальные ответы здесь, я нашел самый быстрый способ исправить поврежденный репозиторий git с помощью следующих команд (выполнить в рабочем каталоге git, который содержит эту
.git
папку):Сначала будут удалены все пустые объектные файлы, которые вызывают повреждение хранилища в целом, а затем извлечены недостающие объекты (а также последние изменения) из удаленного хранилища, а затем будет выполнена полная проверка хранилища объектов . Что, на данный момент, должно произойти без каких-либо ошибок (хотя могут быть некоторые предупреждения!)
источник
Эта ошибка происходит со мной, когда я нажимаю коммит и мой компьютер зависает. Вот как я это исправлю.
Шаги, чтобы исправить
показать пустой / поврежденный объектный файл
убери это
Я получил
fatal: bad object HEAD
сообщениеЯ удаляю
index
для сбросаНеустранимый: не удалось разобрать объект 'HEAD'.
просто чтобы проверить, что происходит
печатает последние 2 строки
tail -n 2
ветки журнала, чтобы показать мои последние 2commit hash
Я выбираю последний
commit hash
показывает все мои файлы,
deleted
потому что я удалил.git/index
файлпродолжить сброс
проверить мое исправление
Примечание: шаги начинаются, когда я попал на этот вопрос и использовал ответы в качестве ссылки.
источник
Я решил это, удалив различные пустые файлы, которые обнаружил git fsck, и затем запустил простое git pull.
Я разочарован тем, что теперь, когда даже файловые системы реализуют журналирование и другие «транзакционные» методы, чтобы сохранить здравый смысл, git может перейти в поврежденное состояние (и не сможет восстановиться сам по себе) из-за сбоя питания или нехватки места на устройстве.
источник
У меня была та же самая проблема: после извлечения удаленного хранилища, когда я сделал состояние git, я получил: «ошибка: объектный файл (...) пуст» «фатальный: свободный объект (...) поврежден»
Я решил это так:
Я не знаю точно, что произошло, но эти инструкции, казалось, сделали все чисто.
источник
cd .git/ && find . -type f -empty -delete
Потому что мне приходится регулярно перезагружать виртуальную машину, поэтому почему-то эта проблема случается со мной очень часто. После нескольких раз я понял, что не могу повторять процесс, описанный @ Nathan-Vanhoudnos, каждый раз, когда это происходит, хотя он всегда работает. Тогда я выяснил следующее более быстрое решение.
Шаг 1
Переместите весь репо в другую папку.
Шаг 2
Снова клонируйте репо из оригинала.
Шаг 3
Удалите все в новом репо, кроме папки .git .
Шаг 4
Перемещение Все , что от temp_repo к новому репо за исключением в .git папки.
Шаг 5
Удалите temp_repo , и все готово.
Я уверен, что через несколько раз вы сможете сделать это очень быстро.
источник
git clone source_to_current_repo.git clean_repo
, 2) сделайте резервную копию старой папки .git, 3) скопируйте чистую папку .git.Это все. Может быть, это не самый лучший способ, но я думаю, что это так практично.
источник
В моем случае эта ошибка произошла из-за того, что я набирал сообщение о коммите и мой блокнот выключился.
Я сделал эти шаги, чтобы исправить ошибку:
git checkout -b backup-branch
# Создать резервную веткуgit reset --hard HEAD~4
# Сброс на коммит, где все работает хорошо. В моем случае мне пришлось вернуть 4 коммита в голове, то есть до тех пор, пока моя голова не окажется в точке, до которой я набрал сообщение о коммите. Перед выполнением этого шага скопируйте хэш коммитов, которые вы сбросите, в моем случае я скопировал хэш 4 последних коммитовgit cherry-pick <commit-hash>
# Вишня выбирает сброшенные коммиты (в моем случае это 4 коммита, поэтому я проделал этот шаг 4 раза) из старой ветви в новую.git push origin backup-branch
# Нажмите на новую ветку, чтобы убедиться, что все работает хорошоgit branch -D your-branch
# Удалить ветку локально ('your-branch' - ветка с проблемой)git push origin :your-branch
# Удалить ветку с удаленногоgit branch -m backup-branch your-branch
# Переименуйте резервную ветвь, чтобы получить имя ветки, в которой возникла проблемаgit push origin your-branch
# Нажмите новую веткуgit push origin :backup-branch
# Удалить резервную ветку с удаленногоисточник
решить мою проблему
источник
git status
так как некоторые из них пусты.Вот действительно простой и быстрый способ решения этой проблемы, если у вас есть локальное репо со всеми необходимыми ветками и коммитами, и если вы в порядке с созданием нового репо (или удалением репо сервера и созданием нового) на своем месте)
Это сохраняет всю историю коммитов и веток, которые у вас были в вашем локальном репо.
Если у вас есть соавторы в репо, то я думаю, что во многих случаях все ваши соавторы должны также изменять удаленный URL-адрес своего локального репо и, при необходимости, выдвигать любые коммиты, которые у них есть, которых нет на сервере.
Это решение сработало для меня, когда я столкнулся с этой же проблемой. У меня был один сотрудник. После того, как я перенес свое локальное репо в новое удаленное репо, он просто изменил свое локальное репо, чтобы оно указывало на URL удаленного репо, и все работало нормально.
источник
У меня была такая же проблема после того, как мой ноутбук сломался. Возможно, потому что это был большой репозиторий, у меня было довольно много поврежденных объектных файлов, которые появлялись только по одному при вызове
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
перенаправляет сообщение об ошибке на стандартный вывод, чтобы иметь возможность его 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
.источник
Пойдем просто .. только в том случае, если вы загрузили исходный код в удаленный репозиторий git
проверь свой мерзавец
удалить пустой объектный файл (все)
проверьте свой мерзавец снова.
вытащить свой источник из удаленного Git
источник
Я сталкиваюсь с этой проблемой много с виртуальными машинами.
Для меня работает следующее:
Если вы хотите сэкономить некоторые загрузки - зайдите в свой файловый менеджер и удалите все файлы в папке, которые уже зафиксированы, и оставьте в ваших папках / vendor и / node_modules (я работаю с composer и npm).
затем просто создайте новый репо
добавить свой пульт
и получить ветку / все это
и проверить это
тогда вы должны быть в точке до ошибки.
Надеюсь это поможет.
С уважением.
источник
Я сталкиваюсь с той же проблемой, и я использую очень простой способ ее устранения. Я обнаружил, что эти пропавшие файлы существуют на компьютере моего товарища по команде.
Я скопировал эти файлы один за другим на git-сервер (всего 9 файлов), и это решило проблему.
источник
Я и мои коллеги несколько раз сталкивались с этой же проблемой, и для ее решения мы просто делаем шаги, которые я опишу ниже. Это не самое элегантное решение, которое можно найти, но оно работает без потери данных.
old_project
для этого примера).git clone
.old_project
(кроме.git
каталога) во вновь созданный каталог проекта.Я надеюсь, что это помогает...
источник
Вот способ решить проблему, если ваше публичное репо на github.com работает, но ваше локальное репо повреждено. Имейте в виду, что вы потеряете все коммиты, которые вы сделали в локальном репо.
Хорошо, так что у меня есть один репо локально, который дает мне это
object empty error
, и тот же репо на github.com, но без этой ошибки. Поэтому я просто клонировал репо, работающее с github, а затем скопировал все из поврежденного репо (кроме папки .git) и вставил клонированное репо, которое работает.Это может быть не практичным решением (поскольку вы удаляете локальные коммиты), однако вы сохраняете код и исправленный контроль версий.
Не забудьте сделать резервную копию перед применением этого подхода.
источник
В моем случае мне было не важно вести историю локальных коммитов. Так что, если это относится и к вам, вы можете сделать это в качестве быстрой альтернативы решениям выше:
Вы просто заменяете поврежденный
.git/
каталог на чистый.Предположим, что следующий каталог для вашего проекта с испорченным git:
projects/corrupt_git/
cp projects/corrupt_git projects/backup
- (необязательно) сделать резервную копиюgit clone [repo URL] projects/clean_git
- так что вы получитеprojects/clean_git
rm -rf corrupt_git/.git/
удалить поврежденную папку .gitmv clean_git/.git/ corrupt_git/
- переместить чистый мерзавец вcorrupt_git/.git
git status
вprojects/corrupt_git
- чтобы убедиться, что это сработалоисточник
Скопируйте все (в папке, содержащей .git) в резервную копию, затем удалите все и перезапустите. Убедитесь, что у вас есть под рукой git remote:
затем
Затем объедините все новые файлы вручную и попробуйте включить компьютер.
источник
Была такая же проблема после проверки мастера из чистой ветки. Через некоторое время я узнал много модифицированных файлов в мастере. Я не знаю, почему они были там, после переключения с чистой ветки. В любом случае, потому что измененные файлы не имели смысла для меня, я просто спрятал их, и ошибка исчезла.
git:(master) git stash
источник
если у вас есть старая резервная копия и вы спешите:
создайте НОВОЕ РЕЗЕРВНОЕ КОПИРОВАНИЕ вашего текущего пути проекта.
.git
в корзину (никогда не удаляйте).git
из старой резервной копииgit pull
(создаст конфликты слияния)./src
(никогда не удаляйте)git gui
, нажмите и ... хлопайте в ладоши!источник
Решение из двенадцати шагов, описанное выше, также помогло мне выйти из затора. Спасибо. Ключевые шаги должны были войти:
и удалите все пустые объекты
Затем получим две строки с поркой:
С возвращенными значениями
В этот момент у меня больше не было ошибок, поэтому я сделал резервную копию своих самых последних файлов. Затем сделайте git pull с последующим git push. Скопировал мои резервные копии в мой файл репозитория git и сделал еще один толчок git. Это актуально для меня.
источник
Я исправил ошибку в git: объектный файл пуст:
Надеется, что это помогает.
источник
Это также случается со мной почти регулярно. Я не сделал протокол, когда это происходит точно, но у меня есть подозрение, что это происходит всякий раз, когда моя виртуальная машина существует «неожиданно». Если я закрываю окно виртуальной машины (я использую Ubuntu 18.04) и начинаю снова, все всегда (?) Работает. Но если окно виртуальной машины все еще открыто, когда мой ноутбук выключен (хост-система Windows), то я сталкиваюсь с этой проблемой довольно часто.
Что касается всех ответов, приведенных здесь:
спасибо - они очень полезны; Я обычно сохраняю локальную копию своего кода, восстанавливаю репозиторий с удаленного компьютера и перемещаю резервную копию обратно в локальную папку.
так как основная проблема на самом деле не проблема git, а проблема виртуальной машины и / или Linux, мне интересно, не должен ли быть способ излечить причину, а не симптомы? Разве такого рода ошибки не указывают на то, что некоторые изменения файловой системы не «применяются» в любое разумное время, а только кэшируются? (см., например, /unix/464184/are-file-edits-in-linux-directly-saved-into-disk ) - мне кажется, что виртуальные машины Linux не fsynch их вещи достаточно часто. Вопрос о том, является ли это проблемой Oracle VirtualBox (которая в остальном работает очень хорошо) или гостевой файловой системы, или некоторых настроек, которые мы все пропускаем, не входит в мои компетенции. Но я был бы счастлив, если бы кто-то мог пролить свет на это.
источник
На самом деле у меня была такая же проблема. Имейте копию своего кода, прежде чем пытаться это.
я только что сделал
git reset HEAD~
мой последний коммит был отменен, потом я его повторил, проблема решена!
источник
Предупреждение: Имея больше опыта, я понимаю, что это ядерный вариант, и его обычно не следует делать, и он ничему не учит. Однако в редких случаях для личных проектов я все еще находил это полезным, поэтому я оставляю это.
Если вы не заботитесь о сохранении своих исторических коммитов, просто бегите
Затем ответьте «да» на все вопросы об удалении файлов, защищенных от записи. Проблема решена в течение минуты.
источник