Ответ 1

Похоже, у вас есть поврежденный древовидный объект. Вам нужно будет получить этот объект от кого-то другого. Надеюсь, у них будет неповрежденная версия.

Фактически вы можете восстановить его, если вы не можете найти допустимую версию от кого-то другого, угадывая, в каких файлах они должны быть. Вы можете посмотреть, соответствуют ли даты и время объектам. Это могут быть связанные с капли. Вы можете вывести структуру древовидного объекта из этих объектов.

Посмотрите Скотт Чакон Git Скринкасты относительно внутренних элементов Git. Это покажет вам, как Git работает под капотом и как заниматься этим детективным делом, если вы действительно застряли и не можете получить этот объект у кого-то другого.

Ответ 2

У меня была такая же проблема (не знаю почему).

Это исправление требует доступа к неповрежденной удаленной копии репозитория и сохранит вашу локально рабочую копию в целости.

Но у него есть некоторые недостатки:

• Вы потеряете запись каких-либо коммитов, которые не были нажаты, и вам придется их повторно подтвердить.
• Вы потеряете любые штампы.

Исправление

Выполните эти команды из родительского каталога над вашим репо (замените "foo" на имя вашей папки проекта):

• Создайте резервную копию коррумпированного каталога:
  cp -R foo foo-backup
• Создайте новый клон удаленного репозитория в новом каталоге:
  git clone [email protected]:foo foo-newclone
• Удалить поврежденный .git подкаталог:
  rm -rf foo/.git
• Переместить вновь клонированный подкаталог .git в foo:
  mv foo-newclone/.git foo
• Удалить оставшуюся часть временного нового клона:
  rm -rf foo-newclone

В Windows вам нужно будет использовать:

• copy вместо cp -R
• rmdir /S вместо rm -rf
• move вместо mv

Теперь foo имеет исходный подкаталог .git, но все локальные изменения все еще существуют. git status, commit, pull, push и т.д. работают снова, как должны.

Ответ 3

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

Сначала создайте резервную копию локальных файлов. Затем сделайте это из корня рабочего дерева:

rm -fr .git
git init
git remote add origin [your-git-remote-url]
git fetch
git reset --mixed origin/master
git branch --set-upstream-to=origin/master master  

Затем при необходимости скопируйте любые измененные файлы.

Ответ 4

Работа с VM, в моем ноутбуке, батарея скончалась, получила эту ошибку;

error: object file.git/objects/ce/theRef - пустая ошибка: объект файл .git/objects/ce/theRef пуст фатальный: свободный объект theRef (хранится в .git/objects/ce/theRef) поврежден

Мне удалось вернуть репо с двумя командами и без потери работы (измененные файлы/незафиксированные изменения)

find .git/objects/ -size 0 -exec rm -f {} \;
git fetch origin

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

git версия 1.9.1

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

Ответ 5

Мой компьютер разбился, когда я писал сообщение о фиксации. После перезагрузки рабочее дерево было таким, каким я его оставил, и я смог успешно выполнить свои изменения.

Однако, когда я пытался запустить git status, я получил

error: object file .git/objects/xx/12345 is empty
fatal: loose object xx12345 (stored in .git/objects/xx/12345 is corrupt

В отличие от большинства других ответов, я не пытался восстановить данные. Мне просто понадобилось Git, чтобы перестать жаловаться на пустой файл объекта.

Обзор

"Объектный файл" - это Git хешированное представление реального файла, о котором вы заботитесь. Git считает, что у него должна быть хешированная версия some/file.whatever, хранящаяся в .git/object/xx/12345, и исправление ошибки оказалось в основном вопросом выяснения того, какой файл должен представлять "свободный объект".

Подробнее

Возможные варианты:

• Удалить пустой файл
• Получить файл в состоянии, приемлемом для Git

Подход 1: удаление объектного файла

Первое, что я попробовал, - это просто перемещение объектного файла

mv .git/objects/xx/12345 ..

Это не сработало - Git начал жаловаться на неработающую ссылку. Подход 2.

Подход 2: Исправьте файл

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

$> # Find out which file the blob object refers to
$> git fsck
broken link from    tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
           to    blob xx12345
missing blob xx12345

$> git ls-tree 2d926
...
10064 blob xx12345  your_file.whatever

Это говорит вам, какой файл должен содержать пустой объект. Теперь вы можете его восстановить.

$> git hash-object -w path/to/your_file.whatever

После этого я проверил .git/objects/xx/12345, он больше не был пуст, а Git переставал жаловаться.

Ответ 6

Try

git stash

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

Ответ 7

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

Я начал с рассмотрения того, сколько коммитов я не нажал на удаленное репо, таким образом:

gitk &

Если вы не используете этот инструмент, это очень удобно - доступно во всех операционных системах, насколько я знаю. Это указывало на то, что у моего пульта не хватало двух коммитов. Поэтому я нажал на метку, указывающую последнюю удаленную фиксацию (обычно это будет /remotes/origin/master), чтобы получить хеш (хэш имеет длину 40 символов, но для краткости я использую 10 здесь - это обычно работает в любом случае).

Вот он:

14c0fcc9b3

Затем я нажимаю на следующую фиксацию (т.е. на первой, которой нет на пульте дистанционного управления), и получаю там хэш:

04d44c3298

Затем я использую оба из них, чтобы сделать патч для этого фиксации:

git diff 14c0fcc9b3 04d44c3298 > 1.patch

Затем я сделал то же самое с другим отсутствующим фиксатором, то есть я использовал хэш коммита до и хеш самого коммита:

git diff 04d44c3298 fc1d4b0df7 > 2.patch

Затем я перешел в новый каталог, клонировал репо с удаленного:

git clone [email protected]:username/repo.git

Затем я переместил файлы исправлений в новую папку и применил их и передал их с их точными сообщениями фиксации (они могут быть вставлены из окна git log или gitk):

patch -p1 < 1.patch
git commit

patch -p1 < 2.patch
git commit

Это восстановило вещи для меня (и обратите внимание, что, вероятно, более быстрый способ сделать это для большого количества коммитов). Однако я был заинтересован в том, можно ли восстановить дерево в поврежденном репо, и ответ может быть. С восстановленным репо, как указано выше, выполните эту команду в сломанной папке:

git fsck 

Вы получите что-то вроде этого:

error: object file .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d is empty
error: unable to find ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d
error: sha1 mismatch ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d

Чтобы сделать ремонт, я сделал бы это в сломанной папке:

rm .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d
cp ../good-repo/.git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d

то есть. удалите поврежденный файл и замените его на хороший. Возможно, вам придется делать это несколько раз. Наконец, будет точка, в которой вы можете запустить fsck без ошибок. Вероятно, у вас в отчете будут "обвисшие фиксации" и "оборванные blob" строки, это следствие ваших переустановок и исправлений в этой папке, и все в порядке. Сборщик мусора удалит их со временем.

Таким образом (по крайней мере, в моем случае) поврежденное дерево не означает, что потерянные коммиты теряются.

Ответ 8

В ответ @user1055643 отсутствует последний шаг:

$ rm -fr .git
$ git init
$ git remote add origin your-git-remote-url
$ git fetch
$ git reset --hard origin/master
$ git branch --set-upstream-to=origin/master master  

Ответ 9

Я тоже получал поврежденную ошибку объекта.

./objects/x/x

Я успешно зафиксировал его, перейдя в каталог поврежденного объекта. Я видел, что пользователи, назначенные этому объекту, были не моими git пользователями. Я не знаю, как это произошло, но я запустил chown git:git в этом файле, а затем снова работал.

Это может быть потенциальным решением проблем некоторых народов, но не обязательно их всех.

Ответ 10

A сбор мусора исправил мою проблему:

git gc --aggressive --prune=now

Завершается некоторое время, но каждый свободный объект и/или поврежденный индекс были исправлены.

Ответ 11

Я получил эту ошибку после того, как мой (оконный) компьютер решил перезагрузить себя. К счастью, мое удаленное репо было актуальным, поэтому я просто сделал новый git -clone..

Ответ 12

Я следил за многими другими шагами здесь; Описание Linus о том, как посмотреть дерево/объекты git и найти то, что пропало, было особенно полезно. git -git восстановить поврежденный blob

Но в конце концов, для меня у меня были потерянные/поврежденные древовидные объекты, вызванные сбоем частичного диска, а древовидные объекты не так легко восстанавливаются/не покрываются этим документом.

В конце концов я переместил конфликтующий objects/<ha>/<hash> в сторону и использовал git unpack-objects с файлом пакета из разумно обновленного клона. Он смог восстановить отсутствующие объекты дерева.

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

Ответ 13

Runnning git stash; git stash pop исправил мою проблему

Ответ 14

Для меня это произошло из-за сбоя питания при выполнении git push.

Сообщения выглядели следующим образом:

$ git status
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
fatal: loose object c238824eb3fb602edc2c49fccb535f9e53951c74 (stored in .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74) is corrupt

Я пробовал такие вещи, как git fsck, но это не помогло. Поскольку авария произошла во время git push, это, очевидно, произошло во время перезаписи на стороне клиента, которая происходит после обновления сервера. Я огляделся и понял, что c2388 в моем случае был объектом фиксации, потому что он упоминался в записи в .git/refs. Поэтому я знал, что смогу найти c2388, когда посмотрю на историю (через веб-интерфейс или второй клон).

Во втором клоне я сделал git log -n 2 c2388, чтобы идентифицировать предшественника c2388. Затем я вручную изменил .git/refs/heads/master и .git/refs/remotes/origin/master как предшественник c2388 вместо c2388. Тогда я мог бы сделать git fetch. git fetch несколько раз не выполнялся для конфликтов на пустых объектах. Я удалил каждый из этих пустых объектов до тех пор, пока git fetch не удался. Это исцелило хранилище.

Ответ 15

Я решил так: Я решил просто скопировать неповрежденный объектный файл из резервного копирования в исходный репозиторий. Это сработало так же хорошо. (Кстати: если вы не можете найти объект в .git/objects/по его имени, он, вероятно, был [упакован] [пакет], чтобы сохранить пространство.)

Ответ 16

У меня была такая же проблема в моем удаленном репозитории git. После долгих поисков неисправностей я понял, что один из моих коллег совершил коммит, в котором некоторые файлы в .git/objects имели разрешения 440 (r-r -----) вместо 444 (r-r-r -). Попросив коллегу изменить разрешения с "объектами chmod 444 -R" внутри открытого репозитория git, проблема была исправлена.

Ответ 17

У нас здесь был случай. Случилось так, что проблема заключалась в том, что владельцем коррумпированного файла был root, а не обычный пользователь. Это было вызвано фиксацией на сервере после того, как кто-то сделал "sudo su -".

Сначала укажите свой поврежденный файл:

$> git fsck --full

Вы должны получить ответ, подобный этому:

fatal: loose object 11b25a9d10b4144711bf616590e171a76a35c1f9 (stored in .git/objects/11/b25a9d10b4144711bf616590e171a76a35c1f9) is corrupt

Перейдите в папку, в которой находится поврежденный файл, и выполните:

$> ls -la

Проверьте права собственности на поврежденный файл. Если это другое, просто вернитесь к корню вашего репо и выполните:

$> sudo chown -R YOURCORRECTUSER:www-data .git/

Надеюсь, что это поможет!

Ответ 18

У меня была такая проблема. Моя особая проблема была вызвана сбоем системы, который исказил самую последнюю фиксацию (и, следовательно, также ведущую ветвь). Я не подтолкнул и хотел переделать эту фиксацию. В моем конкретном случае я смог справиться с этим следующим образом:

• Сделайте резервную копию .git/: rsync -a .git/ git-bak/
• Проверьте .git/logs/HEAD и найдите последнюю строку с допустимым идентификатором фиксации. Для меня это было второе последнее совершение. Это было хорошо, потому что у меня все еще были версии рабочего каталога файла, и поэтому каждая версия, которую я хотел.
• Создайте ветвь при этом фиксации: git branch temp <commit-id>
• повторно выполните ломаную фиксацию с файлами в рабочем каталоге.
• git reset master temp, чтобы переместить ведущую ветвь на новую фиксацию, сделанную вами на шаге 2.
• git checkout master и убедитесь, что он выглядит правильно с помощью git log.
• git branch -d temp.
• git fsck --full, и теперь должно быть безопасно удалять любые поврежденные объекты, обнаруженные fsck.
• Если все выглядит хорошо, попробуйте нажать. Если это работает,

Это сработало для меня. Я подозреваю, что это довольно распространенный сценарий, поскольку самая последняя фиксация наиболее вероятна для того, чтобы быть поврежденным, но если вы потеряете еще одну спину, вы, вероятно, можете использовать такой метод, используя осторожное использование git cherrypick, и reflog в .git/logs/HEAD.

Ответ 19

Когда у меня возникла эта проблема, я сделал резервную копию моих недавних изменений (поскольку я знал, что я изменил), затем удалил этот файл, на который он жаловался .git/location. Затем я сделал git pull. Будьте осторожны, хотя это может не сработать для вас.

Ответ 20

Добавление в кубический салат: 6. Измените .git/config, [remote "origin"], url на правильный URL-адрес сервера, который состоит из user, host and dirrectory. Вы можете найти его в backup -Directory.

Ответ 21

Просто удалите папку .git и добавьте ее снова. Это простое решение работало для меня.