I had a similar problem. My laptop ran out of battery during a Git operation. Boo.
I didn’t have any backups. (N.B. Ubuntu One is not a backup solution for Git; it will helpfully overwrite your sane repository with your corrupted one.)
To the Git wizards, if this was a bad way to fix it, please leave a comment. It did, however, work for me… at least temporarily.
Step 1: Make a backup of folder .git (in fact I do this in between every step that changes something, but with a new copy-to name, e.g., .git-old-1, .git-old-2, etc.):
cd ~/workspace/mcmc-chapter
cp -a .git .git-old
Step 2: Run git fsck --full
git fsck --full
error: object file .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e is empty
fatal: loose object 8b61d0135d3195966b443f6c73fb68466264c68e (stored in .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e) is corrupt
Step 3: Remove the empty file. I figured what the heck; it’s blank anyway.
rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e
rm: remove write-protected regular empty file `.git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e'? y
Step 3: Run git fsck again. Continue deleting the empty files. You can also cd into the .git directory and run find . -type f -empty -delete -print to remove all empty files. Eventually Git started telling me it was actually doing something with the object directories:
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
Step 4: After deleting all of the empty files, I eventually came to git fsck actually running:
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
Step 5: Try git reflog. Fail because my HEAD is broken.
git reflog
fatal: bad object HEAD
Step 6: Google. Find this. Manually get the last two lines of the reflog:
tail -n 2 .git/logs/refs/heads/master
f2d4c4868ec7719317a8fce9dc18c4f2e00ede04 9f0abf890b113a287e10d56b66dbab66adc1662d Nathan VanHoudnos <nathanvan@gmail.com> 1347306977 -0400 commit: up to p. 24, including correcting spelling of my name
9f0abf890b113a287e10d56b66dbab66adc1662d af9fc0c5939eee40f6be2ed66381d74ec2be895f Nathan VanHoudnos <nathanvan@gmail.com> 1347358589 -0400 commit: fixed up to page 28
Step 7: Note that from Step 6 we learned that the HEAD is currently pointing to the very last commit. So let’s try to just look at the parent commit:
git show 9f0abf890b113a287e10d56b66dbab66adc1662d
commit 9f0abf890b113a287e10d56b66dbab66adc1662d
Author: Nathan VanHoudnos <nathanvan@XXXXXX>
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
It worked!
Step 8: So now we need to point HEAD to 9f0abf890b113a287e10d56b66dbab66adc1662d.
git update-ref HEAD 9f0abf890b113a287e10d56b66dbab66adc1662d
Which didn’t complain.
Step 9: See what fsck says:
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
Step 10: The invalid sha1 pointer in cache-tree seemed like it was from a (now outdated) index file (source). So I killed it and reset the repository.
rm .git/index
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
Step 11: Looking at the fsck again…
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
The dangling blobs are not errors. I’m not concerned with master.u1conflict, and now that it is working I don’t want to touch it anymore!
Step 12: Catching up with my local edits:
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")
git commit -a -m "recovering from the git fiasco"
[master 7922876] recovering from the git fiasco
3 files changed, 12 insertions(+), 94 deletions(-)
git add tex/sept2012_code/example-code-testing.R
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
Содержание
- [Solved-1 Solution] How to fix GIT error: object file is empty?
- Error Description:
- Solution 1:
- Related Searches to How to fix GIT error: object file is empty ?
- How can I fix the Git error «object file . is empty»?
- 26 Answers
- Steps to fix
- Как исправить ошибку Git «объектный файл. пуст»?
- 27 ответы
- Шаги, чтобы исправить
[Solved-1 Solution] How to fix GIT error: object file is empty?
Error Description:
- When we try to commit changes, we get this error:
click below button to copy the code. By Git tutorial team
Solution 1:
Step 1: Make a backup of .git (in fact I do this in between every step that changes something, but with a new copy-to name, e.g. .git-old-1, .git-old-2, etc.):
click below button to copy the code. By Git tutorial team
Step 2: Run git fsck —full
click below button to copy the code. By Git tutorial team
Step 3: Remove the empty file.
click below button to copy the code. By Git tutorial team
Step 3: Run git fsck again. Continue deleting the empty files. We can also cd into the .gitdirectory and run find . -type f -empty -delete -print to remove all empty files. Eventually git will start to tell it was actually doing something with the object directories:
click below button to copy the code. By Git tutorial team
Step 4: After deleting all of the empty files, we eventually come to git fsck actually running:
click below button to copy the code. By Git tutorial team
Step 5: Try git reflog. Fail because the HEAD is broken.
click below button to copy the code. By Git tutorial team
Step 6: Google. Find thisManually get the last two lines of the reflog:
click below button to copy the code. By Git tutorial team
Step 7: Note that from Step 6 we learned that the HEAD is currently pointing to the very last commit. So let’s try to just look at the parent commit:
click below button to copy the code. By Git tutorial team
Step 8: So now we need to point HEAD to 9f0abf890b113a287e10d56b66dbab66adc1662d.
click below button to copy the code. By Git tutorial team
Step 9: See what fsck says:
click below button to copy the code. By Git tutorial team
Step 10: The invalid sha1 pointer in cache-tree seemed like it was from a (now outdated) index file .So we kill it and reset the repo.
click below button to copy the code. By Git tutorial team
Step 11: Looking at the fsck again.
click below button to copy the code. By Git tutorial team
The dangling blobs are not errors
Step 12: Catching up with the local edits:
click below button to copy the code. By Git tutorial team
World’s No 1 Animated self learning Website with Informative tutorials explaining the code and the choices behind it all.
Источник
How can I fix the Git error «object file . is empty»?
When I try to commit changes, I get this error:
I tried git fsck I’ve got:
How can I solve this error?
26 Answers
I had a similar problem. My laptop ran out of battery during a Git operation. Boo.
I didn’t have any backups. (N.B. Ubuntu One is not a backup solution for Git; it will helpfully overwrite your sane repository with your corrupted one.)
To the Git wizards, if this was a bad way to fix it, please leave a comment. It did, however, work for me. at least temporarily.
Step 1: Make a backup of folder .git (in fact I do this in between every step that changes something, but with a new copy-to name, e.g., .git-old-1, .git-old-2, etc.):
Step 2: Run git fsck —full
Step 3: Remove the empty file. I figured what the heck; it’s blank anyway.
Step 3: Run git fsck again. Continue deleting the empty files. You can also cd into the .git directory and run find . -type f -empty -delete -print to remove all empty files. Eventually Git started telling me it was actually doing something with the object directories:
Step 4: After deleting all of the empty files, I eventually came to git fsck actually running:
Step 5: Try git reflog . Fail because my HEAD is broken.
Step 6: Google. Find this. Manually get the last two lines of the reflog:
Step 7: Note that from Step 6 we learned that the HEAD is currently pointing to the very last commit. So let’s try to just look at the parent commit:
Step 8: So now we need to point HEAD to 9f0abf890b113a287e10d56b66dbab66adc1662d.
Which didn’t complain.
Step 9: See what fsck says:
Step 10: The invalid sha1 pointer in cache-tree seemed like it was from a (now outdated) index file (source). So I killed it and reset the repository.
Step 11: Looking at the fsck again.
The dangling blobs are not errors. I’m not concerned with master.u1conflict, and now that it is working I don’t want to touch it anymore!
Step 12: Catching up with my local edits:
The Git object files have gone corrupt (as pointed out in other answers as well). This can happen during machine crashes, etc.
I had the same thing. After reading the other top answers here I found the quickest way to fix the broken Git repository with the following commands (execute in the Git working directory that contains the .git folder):
(Be sure to back up your Git repository folder first!)
This will first remove any empty object files that cause corruption of the repository as a whole, and then fetch down the missing objects (as well as latest changes) from the remote repository, and then do a full object store check. Which, at this point, should succeed without any errors (there may be still some warnings though!)
PS. This answer suggests you have a remote copy of your Git repository somewhere (e.g. on GitHub) and the broken repository is the local repository that is tied to the remote repository which is still intact. If that is not the case, then do not attempt to fix it the way I recommend.
This error happens to me when I am pushing my commit and my computer hangs.
This is how I’ve fix it.
Steps to fix
Show the empty/corrupt object file
I got fatal: bad object HEAD message
I remove the index for the reset.
fatal: Could not parse object ‘HEAD’.
Just to check what’s happening
It prints the last two lines, tail -n 2 , of the log branch to show my last two commit hashes.
I pick the last commit hash
It shows all my file as deleted, because i removed the .git/index file
Continue to the reset
I solved this removing the various empty files that git fsck was detecting, and then running a simple Git pull.
I find it disappointing that now that even filesystems implement journaling and other «transactional» techniques to keep the file system sane, Git can get to a corrupted state (and not be able to recover by itself) because of a power failure or space on the device.
I just had the same issue: after pulling the distant repository, when I did a git status I got:
«error: object file (. ) is empty»
«fatal: loose object (. ) is corrupted»
The way I resolved this was to:
- git stash
- removing the Git file in error (I am not sure that it was necessary)
- git stash clear
I don’t know exactly what things happened, but that instructions seemed to make everything clean.
Because I have to reboot my VM regularly, somehow this problem happens to me very often. After few times of it, I realized I cannot repeat the process described by Nathan Vanhoudnos every time this happens, though it always works. Then I figured out the following faster solution.
Step 1
Move your entire repository to another folder.
Step 2
Clone the repository from origin again.
Step 3
Remove Everything under the new repository except the .git folder.
Step 4
Move everything from the temp_repository to the new repository except the .git folder.
Step 5
Remove the temp_repository, and we are done.
After a few times, I’m sure you can do these procedures very quickly.
- Move your app folder to make a backup, i.e., mv app_folder app_folder_bk (it is like a git stash)
- git clone your_repository
- Finally, open a merge tool (I use the Meld diff viewer on Linux or WinMerge on Windows) and copy the changes from right (app_folder_bk) to left (new app_folder) (it is like a git stash apply).
That’s all. Maybe it is not the best way, but I think it is so practical.
This resolved my problem:
I run into this problem a lot with virtual machines.
For me the following works:
If you want to save yourself some downloads — go in your file explorer and delete all files in the folder that are already committed and leave in your /vendor and /node_modules (I work with PHP Composer and npm) folders.
Then just create a new repository:
Add your remote
And fetch the branch / all of it
And check it out
Then you should be at the point before the error.
In my case, this error occurred because I was typing the commit message and my notebook turned off.
I did these steps to fix the error:
- git checkout -b backup-branch # Create a backup branch
- git reset —hard HEAD
4 # Reset to the commit where everything works well. In my case, I had to back four commits in the head, that is until my head be at the point before I was typing the commit message. Before doing this step, copy the hash of the commits you will reset. In my case I copied the hash of the four last commits.
My colleagues and I have crossed several times with this same problem and to solve it we simply do the steps that I describe below. It is not the most elegant solution that can be found but it works without loss of data.
- Rename the current working directory. ( old_project for this example).
- Clone the repository within a new directory using git clone .
- On the command line, change the working directory to the newly created project and switch to the branch you have been working on.
- Copy all files and directories within old_project (except the .git directory) to the newly created project directory.
- Check your working tree status (note that there are many more changes than you expect) and then commit the changes.
I hope it helps.
I am assuming you have a remote with all relevant changes already pushed to it. I did not care about local changes and simply wanted to avoid deleting and recloning a large repository. If you do have important local changes you might want to be more careful.
I had the same problem after my laptop crashed. Probably because it was a large repository I had quite a few corrupt object files, which only appeared one at a time when calling git fsck —full , so I wrote a small shell one-liner to automatically delete one of them:
$ sudo rm `git fsck —full 2>&1 | grep -oE -m 1 «.git/objects/[0-9a-f]<2>/[0-9a-f]*»`
- 2>&1 redirects the error message to standard output to be able to grep it
- grep options used:
- -o only returns the part of a line that actually matches
- -E enables advanced regular expressions
- -m 1 make sure only the first match is returned
- [0-9a-f] <2>matches any of the characters between 0 and 9 and a and f if two of them occur together
- [0-9a-f]* matches any number of the characters between 0 and 9 and a and f occurring together
It still only deletes one file at a time, so you might want to call it in a loop like:
The problem with this is, that it does not output anything useful any more, so you do not know when it is finished (it should just not do anything useful after some time).
To «fix» this I then just added a call of git fsck —full after each round like so: $ 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
It now is approximately half as fast, but it does output its «state».
After this I played around some with the suggestions in the answers here and finally got to a point where I could git stash and git stash drop a lot of the broken stuff.
First problem solved
Afterwards I still had the following problem: unable to resolve reference ‘refs/remotes/origin/$branch’: reference broken which could be solved by $ rm repo.gitrefsremotesorigin$branch
I then did a $ git gc —prune=now
$ git remote prune origin
for good measure and
git reflog expire —stale-fix —all
to get rid of error: HEAD: invalid reflog entry $blubb when running git fsck —full .
Источник
Как исправить ошибку Git «объектный файл. пуст»?
Когда я пытаюсь зафиксировать изменения, я получаю эту ошибку:
Я пытался git fsck У меня есть:
Как я могу решить эту ошибку?
задан 29 июля ’12, 03:07
Вы насильно убили git add операция? Ваш жесткий диск заполнен? — cdhowie
Нет, мой жесткий диск не заполнен, я не помню, чтобы я принудительно отключил операцию git add, что, если бы я это сделал? как я могу это решить? — simo
нет, ошибка осталась. — simo
Если этот репозиторий существует в удаленном репозитории, вы можете попробовать скопировать этот файл оттуда в локальный, если он существует в вашем удаленном репозитории. — Attila Szeremi
Я получил эту ошибку, когда мои разрешения в каталоге .git каким-то образом испортились, и у меня не было доступа для чтения. Так что это может произойти в тех случаях, когда файлы не пусты, но в них просто нельзя записать. Исправление разрешений и запуск git fsck позаботился об этом. — Jake Anderson
27 ответы
У меня была аналогичная проблема. Мой ноутбук разрядился во время операции Git. Бу.
У меня не было резервных копий. (Обратите внимание, что Ubuntu One не является решением для резервного копирования для Git; оно перезапишет ваш нормальный репозиторий поврежденным.)
Для мастеров Git, если это был плохой способ исправить это, оставьте комментарий. Однако это сработало для меня. по крайней мере, временно.
Шаг 1: Сделайте резервную копию папки .git (на самом деле я делаю это между каждым шагом, который что-то меняет, но с новым именем копии, например, .git-старый-1, .git-старый-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: Догоняю мои локальные правки:
ответ дан 29 авг.
Хм, мой ноутбук умер во время операции git (SparkleShare пытался зафиксировать мои заметки, когда он умер), и после этого репо было повреждено таким образом. Я следовал вашим шагам до 6, но кажется, что последние несколько коммитов на самом деле должны были быть частью пустых объектных файлов, которые я удалил? На самом деле последние 3 коммита были в основном полностью сломаны, поэтому я ничего не мог сделать. К счастью, мне на самом деле не нужны отдельные коммиты из SparkleShare, и я могу просто скопировать грязный файл с одной машины на другую и объединить. — Ибрагим
Спасибо, я много узнал о некоторых функциях git, а также сэкономил время на важном коммите! По совпадению это было также из-за низкого заряда батареи на ноутбуке. — HarbyUK
мы можем дать этому человеку Нобелевскую премию или что-то в этом роде? Я устроил беспорядок, когда мое съемное устройство было неожиданно удалено, и я приятно удивлен, что смог очистить его с помощью этого рецепта. ты жжешь! — Давид
Если ошибка сохраняется после шага 11 (для git fsck —name-object ) лайк git broken link from tree 61d013* to blob , может потребоваться следовать инструкциям на stackoverflow.com/a/11959590/2062965 — это решило проблему для меня. — стрпитер
Могу ли я предложить шаг 13 с cd
; mkdir recovered; cd recovered; git init; git remote add damaged path/to/damaged; git fetch damaged . После этого шага некоторые потери мощности во время git-rebase связанные с этим повреждения по-прежнему вызывали проблемы. Но с более чистым репозиторием вы теряете оборванные объекты, которые могут быть, а могут и не быть важными (они распространены для рабочего процесса Gerrit), но по крайней мере все локальные ветки восстанавливаются. Выполнение дополнительного шага для копирования неотслеживаемых и игнорируемых файлов из поврежденного репозитория в новый также потенциально полезно. Но на самом деле, спасибо за это! — Эммануэль Лепаж Валле
Объектные файлы Git повреждены (как указано и в других ответах). Это может произойти во время сбоев машины и т. д.
У меня было то же самое. Прочитав другие популярные ответы здесь, я нашел самый быстрый способ исправить сломанный репозиторий Git с помощью следующих команд (выполнить в рабочем каталоге Git, содержащем .git папка):
(Обязательно сначала сделайте резервную копию папки репозитория Git!)
Это будет сначала удалить все пустые объектные файлы которые вызывают повреждение репозитория в целом, а затем достать недостающие предметы (а также последние изменения) из удаленного репозитория, а затем сделать полный проверка хранилища объектов. Что на данный момент должно завершиться успешно без каких-либо ошибок (хотя могут быть некоторые предупреждения!)
PS. Этот ответ предполагает, что у вас где-то есть удаленная копия вашего репозитория Git (например, на GitHub), а сломанный репозиторий — это локальный репозиторий, привязанный к удаленному репозиторию, который все еще не поврежден. Если это не так, то не пытайтесь исправить это так, как я рекомендую.
ответ дан 29 авг.
Спасибо за это, я довольно религиозно нажимаю на свои удаленные ветки, и ваше решение сработало для меня. Сначала я попробовал @mCorr ниже, но после того, как я зафиксировал новые файлы, репо снова стало поврежденным. Этот подход решил это — мистер_тан
Возникла эта проблема после выключения виртуальной машины, в которой я работал с репозиторием git. Это решение сработало отлично. — Жискар Биэмби
Спасибо, Мартин, отличное и компактное решение. Хотя я мог бы поставить этот PS первым, с предупреждением, выделенным жирным шрифтом, чтобы не дать наивным пользователям попробовать то же самое на локальной установке. Как и у Giscard, это возникает у меня при выключении виртуальной машины . будет обновлено, если я найду более постоянное решение, чем делать это каждый раз. — Кларк
VM Crush сделал это и с моим локальным репозиторием git, я могу подтвердить, что это решение работает на 100% в этом случае — Амин.Т
Это было быстрее исправить, чем другие. Спасибо. — Антон
Эта ошибка возникает у меня, когда я нажимаю свою фиксацию, и мой компьютер зависает.
Вот как я это исправил.
Шаги, чтобы исправить
Показать пустой/поврежденный объектный файл
я получил fatal: bad object HEAD сообщение
Я удаляю index для сброса.
фатальный: не удалось проанализировать объект «HEAD».
Просто чтобы проверить, что происходит
Он печатает последние две строки, tail -n 2 , ветки журнала, чтобы показать мои последние два фиксировать хэши.
я выбираю последнее commit hash
Он показывает весь мой файл как удаленный, потому что я удалил .git/index файл
Перейти к сбросу
Проверить мое исправление
ответ дан 29 авг.
Мужик, ты парень. Спас мой день. Большое спасибо! — Майкл Пачеко
Я часто сталкиваюсь с этой проблемой с виртуальными машинами.
Для меня работает следующее:
Если вы хотите сохранить себе несколько загрузок — зайдите в проводник и удалите все файлы в папке, которые уже зафиксированы, и оставьте в своем /продавец и / node_modules (Я работаю с Композитор PHP и НПМ) папки.
Затем просто создайте новый репозиторий:
Добавьте свой пульт
И принеси ветку / всю ее
И проверить это
Тогда вы должны быть в точке перед ошибкой.
ответ дан 29 авг.
В одном скрипте
Хотя пятая команда выдала ошибку( fatal: 1390b51e0218e3b2bf87df572410533c368871fe985807939acae90b65dc5d53cec4225477bd2c3a: not a valid SHA1 это решило проблему для меня! — Филипп Хонсель
Я решил это, удалив различные пустые файлы, которые git fsck обнаруживал, а затем запускал простой Git pull.
Меня разочаровывает тот факт, что теперь, когда даже файловые системы реализуют журналирование и другие «транзакционные» методы для поддержания файловой системы в нормальном состоянии, Git может прийти в поврежденное состояние (и не сможет восстановиться самостоятельно) из-за сбоя питания или свободного места на диске. устройство.
ответ дан 29 авг.
Я уверен, что ответ выше технически лучше, но он перестал работать на шаге 6 и технически был намного выше моей головы. Целесообразным подходом является git pull — мблэквелл8
Я столкнулся с ситуацией, когда после выполнения шагов 1-11 инструкций из ответа Натана (что отлично сработало!), У меня возникла ошибка, в которой говорилось, что refs/origin/master и refs/origin/head не были определены (или что-то вроде тот). git pull исправил это. Поэтому я думаю, что оба решения работают вместе. — Черчилль
Я знаю, что используемые файловые системы обычно ведут журнал только метаданных. Вы также можете включить ведение журнала для данных, но я думаю, что это не по умолчанию из-за накладных расходов (?). Вероятно, поэтому файлы были пустыми . и файловые системы обычно наблюдают за транзакциями для каждого файла, тогда как git имеет несколько изменяемых файлов за транзакцию, поэтому, даже если fs сохраняет согласованность для каждого файла, если git нет, то я думаю, что git приведет к несогласованным состояниям. — Чан Хён Парк
Этот ответ сработал для меня, другие слишком сложны. — собака
Намного более быстрое решение, чем принятый ответ. Всем, кто прокрутил это далеко, следуйте этому ответу, если вы спешите. — Шри Харша Каппала
У меня была такая же проблема: после извлечения удаленного репозитория, когда я сделал git status Я получил:
«ошибка: объектный файл (. ) пуст»
«фатально: незакрепленный объект (. ) поврежден»
Я решил это следующим образом:
- git stash
- удаление файла Git по ошибке (я не уверен, что это было необходимо)
- git stash clear
Я не знаю точно, что произошло, но эти инструкции, казалось, все исправили.
ответ дан 29 авг.
Мне всегда нравятся более простые ответы 🙂 Для шага 2 здесь я использовал команду, указанную в ответе @Nathan VanHoudnos: cd .git/ && find . -type f -empty -delete — мопо922
Я исправил свою ошибку git: объектный файл пуст:
- Сохранение копии всех файлов, которые я редактировал с момента моей последней успешной фиксации/передачи,
- Удаление и повторное клонирование моего репозитория,
- Замена старых файлов моими отредактированными файлами.
ответ дан 29 авг.
Давайте пойдем проще. только в том случае, если вы загрузили исходный код в удаленный репозиторий Git.
Резервные копии .git папку.
Проверьте свой репозиторий Git
Удалить пустые объектные файлы (все)
Снова проверьте свой репозиторий Git.
Извлеките исходный код из удаленного репозитория Git.
ответ дан 29 авг.
В этой ситуации я решаю свою проблему, следуя этой проблеме.
- Удалите папку .git из моего каталога репозитория. (сохраняйте резервную копию для сохранности)
- клонировать мое репо в другой каталог.
- скопируйте папку .git из нового клонированного каталога.
- вставьте в мой предыдущий каталог, где возникает проблема.
проверьте статус git, надеюсь, вы увидите все свои изменения. теперь вы можете зафиксировать и нажать.
ответ дан 10 окт ’21, 06:10
я получил эту ошибку в своей студии Android, и я не знаю, как проверить статус git, но я просто rebuild project в студии Android, и ошибка исчезла. Thank you!! — Вивек Туммар
Мы с коллегами несколько раз сталкивались с этой же проблемой, и для ее решения мы просто делаем шаги, которые я описываю ниже. Это не самое элегантное решение, которое можно найти, но оно работает без потери данных.
- Переименуйте текущий рабочий каталог. ( old_project для этого примера).
- Клонируйте репозиторий в новый каталог, используя git clone .
- В командной строке измените рабочий каталог на только что созданный проект и переключитесь на ветку, над которой вы работали.
- Скопируйте все файлы и каталоги внутри old_project (кроме .git каталог) в только что созданный каталог проекта.
- Проверьте состояние вашего рабочего дерева (обратите внимание, что изменений гораздо больше, чем вы ожидаете), а затем зафиксируйте изменения.
Я надеюсь, что это помогает.
Это решило мою проблему:
ответ дан 29 авг.
это помогло. Спасибо. — Swateek
Если репозиторий чист, вам просто нужно «cd .git/ && найти . -type f -empty -delete && cd — && git pull», вам может потребоваться проверить некоторые файлы в git status так как некоторые из них пусты. — Кодичан
У меня это тоже происходит почти регулярно. Я не составил протокол, когда именно это происходит, но у меня есть подозрение, что это происходит всякий раз, когда мой виртуальная машина (VM) существует «неожиданно». Если я закрою окно виртуальной машины (я использую Ubuntu 18.04 (Bionic Beaver)) и начать заново, все всегда(?) работает. Но если окно виртуальной машины все еще открыто, когда мой ноутбук выключен (хост-система Windows), то я сталкиваюсь с этой проблемой довольно часто.
Что касается всех ответов, приведенных здесь:
спасибо — они очень полезны; Обычно я сохраняю локальную копию своего кода, восстанавливаю репозиторий удаленно и перемещаю резервную копию обратно в локальную папку.
поскольку основная проблема на самом деле не проблема Git, а скорее проблема виртуальной машины и / или Linux, мне интересно, не должно ли быть способа вылечить причину, а не симптомы? Не указывает ли такая ошибка на то, что некоторые изменения файловой системы не «применяются» в любое разумное время, а только кэшируются? (см. например Сохраняются ли изменения файлов в Linux напрямую на диск?) — мне кажется, что виртуальные машины Linux недостаточно часто синхронизируют свои вещи. Является ли это проблемой Oracle VirtualBox (которая в остальном работает очень хорошо), или гостевой файловой системой, или какими-то настройками, которые мы все упускаем из виду, я не знаю. Но я был бы рад, если бы кто-то мог пролить свет на это.
ответ дан 29 авг.
- Переместите папку приложения, чтобы сделать резервную копию, т.е. mv app_folder app_folder_bk (это как мерзавец)
- git clone your_repository
- Наконец, откройте инструмент слияния (я использую Сливаться просмотрщик различий в Linux или WinMerge в Windows) и скопируйте изменения справа (app_folder_bk) влево (новый app_folder) (это как git stash применить).
Это все. Может быть, это не лучший способ, но я думаю, что это так практично.
ответ дан 29 авг.
Это то, что вы должны сделать, когда все локальные изменения переданы в восходящий поток или изменения минимальны, поэтому клонирование выполняется быстрее, чем восстановление. — Аншул Гоял
Вот способ решить проблему, если ваш общедоступный репозиторий на github.com работает, но ваш локальный репозиторий поврежден. Имейте в виду, что вы потеряете все сделанные вами коммиты в локальном репозитории.
Итак, у меня есть один локальный репозиторий, который дает мне это object empty error , и такой же репозиторий на github.com, но без этой ошибки. Так что я просто клонировал работающий репозиторий с GitHub, а затем скопировал все из поврежденного репозитория (кроме .git папку) и вставьте в нее работающий клонированный репозиторий.
Это может быть непрактичным решением (поскольку вы удаляете локальные коммиты), однако вы сохраняете код и исправленный контроль версий.
Не забудьте сделать резервную копию перед применением этого подхода.
ответ дан 29 авг.
В моем случае мне не было важно хранить локальную историю коммитов. Так что, если это относится и к вам, вы можете сделать это в качестве быстрой альтернативы приведенным выше решениям:
Вы в основном просто заменяете поврежденный .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/ — удалить поврежденный .git папку.
- mv clean_git/.git/ corrupt_git/ — переместите чистый git в corrupt_git/.git
- git status in projects/corrupt_git — чтобы убедиться, что это сработало
ответ дан 29 авг.
Я предполагаю, что у вас есть пульт со всеми соответствующими изменениями, уже внесенными в него. Я не заботился о локальных изменениях и просто хотел избежать удаления и повторного клонирования большого репозитория. Если у вас есть важные локальные изменения, вы можете быть более осторожными.
У меня была такая же проблема после поломки ноутбука. Вероятно, из-за того, что это был большой репозиторий, у меня было довольно много поврежденных объектных файлов, которые появлялись только по одному при вызове. 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 it
- GREP используемые варианты:
- -o возвращает только ту часть строки, которая действительно соответствует
- -E включает расширенные регулярные выражения
- -m 1 убедитесь, что возвращается только первое совпадение
- [0-9a-f] <2>соответствует любому из символов от 0 до 9 и a и f, если два из них встречаются вместе
- [0-9a-f]* соответствует любому количеству символов от 0 до 9, а также буквам a и f, встречающимся вместе
Он по-прежнему удаляет только один файл за раз, поэтому вы можете вызвать его в цикле, например:
Проблема с этим в том, что он больше не выводит ничего полезного, поэтому вы не знаете, когда он будет закончен (он просто не должен делать ничего полезного через некоторое время).
Чтобы «исправить» это, я просто добавил вызов 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.gitrefsremotesorigin$branch
Затем я сделал $ git gc —prune=now
$ git remote prune origin
на всякий случай и
git reflog expire —stale-fix —all
избавиться error: HEAD: invalid reflog entry $blubb при беге git fsck —full .
Источник
Background introduction
In the daily development process, we may cause git version library problems due to improper operation. One of the most common problems is that the object file is empty error object-file-is-empty. The general tips are as follows:
error: object file .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0 is empty fatal: loose object 3165329bb680e30595f242b7c4d8406ca63eeab0 (stored in .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0) is corrupt
Solution
-
git init starts all over again, the most violent and direct solution, but then the commit before it disappears. In the short run, the long-term project submission disappears completely. It seems that it is not so good.
-
git clone/fetch clones or pulls other people’s projects back to the latest submission records of that person’s project, which can save some, in case your project is much newer than his.
In short, none of the above is the best solution. The best solution is that we can restore the original git log records of the local project and repair the bad nodes.
Optimal Solution
1. Run git fsck —full
luyi@ubuntu:~/projects/example$ git fsck --full error: object file .git/objects/3a/60046cdd45cf3e943d1294b3cb251a63fb9552 is empty error: object file .git/objects/3a/60046cdd45cf3e943d1294b3cb251a63fb9552 is empty fatal: loose object 3a60046cdd45cf3e943d1294b3cb251a63fb9552 (stored in .git/objects/3a/60046cdd45cf3e943d1294b3cb251a63fb9552) is corrupt
2. Select the empty file and delete rm filepath
luyi@ubuntu:~/projects/example$ rm .git/objects/3a/60046cdd45cf3e943d1294b3cb251a63fb9552 rm: remove write-protected regular empty file '.git/objects/3a/60046cdd45cf3e943d1294b3cb251a63fb9552'? y
3. Running git fsck again — full usually checks for another empty file and deletes it. Once and for all, find. — type F — empty — delete — print deletes all empty files in the. git directory
luyi@ubuntu:~/projects/example/.git$ find . -type f -empty -delete -print ./objects/c6/492f7ad72197e2fb247dcb7d9215035acdca7f ./objects/9f/fe81f4bb7367c00539a9a0d366ff2a7558bfed ./objects/7c/b9a39246389a8417006b9365f6136823034110 ./objects/de/1092e8c90cb025e99501a4be0035753b259572 ./objects/6f/a8c9109f2e0d29095490ca8f4eaf024a6e2dcb
4. At this point, all empty files have been deleted, and then run git fsck — full, or there is a mistake, head pointing element does not exist, is the previous empty file, we have deleted. What about swelling?
luyi@ubuntu:~/projects/example/.git$ git fsck --full Checking object directories: 100% (256/256), done. Checking objects: 100% (103719/103719), done. error: HEAD: invalid sha1 pointer c6492f7ad72197e2fb247dcb7d9215035acdca7f error: refs/heads/ia does not point to a valid object! dangling blob 2a12b47881cd879987df8e50c9d900847c025bf4 dangling blob 5d4a7c616f0e59dd82608979e85d56f7a6785884 dangling blob cd6facde8c37f8389c12f3742185174a0536197b dangling blob c2d0c0fba535d89cca9633d1b0ab780c8199dfd9 dangling blob 5117513970702f484278fd87732135a39588a073 dangling blob ac45f1874a0e42a6b9586594179f9825f3a40fd0 dangling blob c3355ad882b378740822e673d304e2cc091f1412 dangling blob 4d64dedf9f3518f25f7b7e3b1ad0dd6b477e0ce3 dangling blob 2487eae5cc4bfc23bc896c4051cb8f5522664e33 dangling blob 2a1907848af8aea53cb84e392225a5b6c4a81a5b dangling blob 114233d9981a7933eacbff45a2b106ef1b61cfa9 dangling blob 9879ef3dd84a5515719fa7f35f982ac4d6a34e37 dangling blob f5b3bfd49e04c18ad12d590450a306a109b9151c dangling blob 5fdb9f048aead1c85474fbca29b2ee327c821680
5. Get the last two reflog s manually and run tail-n 2. git/logs/refs/heads/ia
luyi@ubuntu:~/projects/example$ tail -n 2 .git/logs/refs/heads/ia 3a0ecb6511eb0815eb49a0939073ee8ac8674f8a 99cb711e331e1a2f9b0d2b1d27b3cdff8bbe0ba5 Lu Yi <luy@jjmmw.com> 1477039998 +0800 commit: nested into app
6.head is currently pointing to the latest record, so let’s take a look at parent commit, which is the penultimate submission of git show 99cb711e331e1a2f9b0d2b1d27b3cdff8bbe0ba5
luyi@ubuntu:~/projects/example$ git show 99cb711e331e1a2f9b0d2b1d27b3cdff8bbe0ba5commit 99cb711e331e1a2f9b0d2b1d27b3cdff8bbe0ba5 Date: Fri Oct 21 16:53:18 2016 +0800 nested into app diff --git a/pzbm/templates/pzbm/base.html b/pzbm/templates/pzbm/base.html index 70331c5..c96d12c 100644 --- a/pzbm/templates/pzbm/base.html +++ b/pzbm/templates/pzbm/base.html @@ -6,7 +6,7 @@
We can see that the content is good.
7. Then we reset the head to point to the penultimate git update-ref HEAD 99cb711e331e1a2f9b0d2b1d27b3cdff8bbe0ba5
luyi@ubuntu:~/projects/example$ git update-ref HEAD 99cb711e331e1a2f9b0d2b1d27b3cdff8bbe0ba5 luyi@ubuntu:~/projects/example$ git s On branch ia Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: pzbm/templates/pzbm/invest_advisor/reports.html
8. Final submission of the following new code is OK. This saves our git log records, just to fix the broken nodes.
Reference link
Self translation how-to-fix-git-error-object-file-is-empty