Как обработать git gc fatal: неверный объект refs/remotes/origin/HEAD ошибка: не удалось запустить repack

Сегодня я случайно попал в список при попытке собрать мусор.

$ git gc
fatal: bad object refs/remotes/origin/HEAD
error: failed to run repack

Как мне с этим бороться?

23 ответа

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

$ mv .git/refs/remotes/origin/HEAD /tmp

(держать его на всякий случай), а затем

$ git gc

работал без жалоб; Я не столкнулся с какими-либо проблемами.

Увидев ответ Трентона, я посмотрел на .git/refs/remotes/origin/HEAD и увидел, что он также указывает на старую ветку, которая теперь удалена.

Но вместо того, чтобы редактировать файл самостоятельно, я попробовал решение Райана:

git remote set-head origin --auto

Он автоматически устанавливает файл в новую ветку, и git gc работал нормально после этого.

Проблема, с которой я столкнулся (это та же проблема, что @Stavarengo, упомянутая в этом комментарии выше), заключается в том, что удаленная ветка по умолчанию (develop в моем случае) был удален, но все еще упоминался в .git/refs/remotes/origin/HEAD,

открытие .git/refs/remotes/origin/HEAD в моем редакторе это показывалось:

ref: refs/remotes/origin/develop

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

ref: refs/remotes/origin/master

Ключом к разгадке было то, что бег git prune показал эту ошибку:

> git prune
warning: symbolic ref is dangling: refs/remotes/origin/HEAD

Слава богу, я нашел это https://makandracards.com/chris-4/54101-fixing-a-git-repo

      fatal: bad object refs/remotes/origin/HEAD
error: failed to run repack

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

cat .git/refs/remotes/origin/HEAD

Если он указывает на несуществующую ветку, выполняется:

git remote set-head origin --auto

с последующим

git gc

исправлю это

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

git remote set-head origin --auto

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

$ git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/master
$ git fetch --prune
$ git gc

Это должно исправить это.

Я столкнулся с этой ошибкой, потому что ветка по умолчанию была изменена с masterк main. Я использовал смесь информации, предоставленной несколькими ответами выше, чтобы решить эту проблему:


Возвращено:

      ref: refs/remotes/origin/master

Чтобы исправить это, я запустил:

      git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main

Я запустил это снова, чтобы перепроверить:

      cat .git/refs/remotes/origin/HEAD

Который вернулся:

      ref: refs/remotes/origin/main

затем git gcа также git pruneработал просто отлично.


Чтобы увидеть, что происходит, я также пробовал:

      git remote set-head origin --auto

Который вернулся:

      origin/HEAD set to main

И это действительно решает проблему, автоматически идентифицируя реф.

git update-ref -d [wrong reference here]

Это решит эту проблему.

Для вышеуказанной проблемы используйте следующий код:

git update-ref -d 'refs/remotes/origin/HEAD'

РМ .git/refs/remotes/origin/HEAD

git GC

Если кто-то получает эту ошибку

      fatal: bad object refs/stash 2
error: https://github.com/Username/repository.git did not send all necessary objects

вот как я исправил

      mv .git/refs/stash\ 2 /tmp
git gc

Приведенное выше решение частично сработало для меня, потому что в моей папке были файлы «desktop.ini» повсюду в репозитории, поскольку он размещен на Google Диске, включая папки «.git», в которых Git хранил свои собственные данные. Git ожидал, что каждый файл в этой папке будет содержать данные Git, а не данные Google Диска, и захлебнулся, пытаясь интерпретировать содержимое файла desktop.ini. Чтобы этого избежать, обязательно включите desktop.iniв .gitignore

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

  1. создайте в репозитории файл "delete.bat" и добавьте в него следующий код

    del /s /q /f /a ".\desktop.ini"

  2. Открыть и открыть текущую папку

  3. бежать delete.batпросто позвонив в cmd

Теперь вы должны быть в состоянии запустить git remote set-head origin --auto

с последующим git gc

Причиной этого для меня была работа со сжатой папкой в ​​Windows. Когда папка была распакована, это повредило файлы пакета, вызвав каскад других странных проблем, таких как невозможность удалить несуществующие ветки.

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

Если вы используете git worktrees, убедитесь, что вы выполняете

git worktree prune

перед запуском

git gc

У меня было повреждено рабочее дерево, и, похоже, это помогло после удаления поврежденного рабочего дерева. git prune сам по себе, похоже, не работал.

Мне помогло попасть в саму папку на моем компьютере, потому что я продолжал получать ошибку

      No such file or directory

всякий раз, когда я бегу

      mv .git/refs/remotes/origin/HEAD /tmp 

$ git gc git prune

После открытия скрытых файлов это можно сделать, нажав cmd+shift+. на Mac или Windows затем ref > Remote > Origin и удалите ненужные файлы.

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

      fatal: bad object refs/remotes/origin/account

Приведенные выше решения по какой-то причине не сработали для меня. Продолжал получать эту ошибку

      mv: cannot stat '.git/refs/remotes/origin/HEAD': No such file or directory

И бегgit gcдал эту ошибку:

      error: bad ref for .git/logs/refs/remotes/origin/account
fatal: bad object refs/remotes/origin/account
fatal: failed to run repack

В моей ситуации удаленная ветка указывала на несуществующую ветку.

Что исправило это для меня, так это удаление ветки

      git branch -D account

а также удалить его из.git/refs/remotes/origin/account

Все работает отлично.

Моя проблема возникла с определенной веткой.
По всей видимости, справочный файл ветки был поврежден. Я вот так исправил.

git checkout main
// Я удалил файл .git \refs\ Heads\branch_xpto
git pull
git checkout branch_xpto

для меня проблема возникла при нажатии из VS Code. Я сделалgit pushвручную в терминале. это сработало.

Для меня удаленная ветка в источнике создавала эту ошибку.

Отредактировано:.git\info\refsИ удалил строку с веткой, вызывающей эту ошибку, в моем случае это ветка функции, которая была отправлена ​​в источник, но не прошла и каким-то образом удалена в источнике.

Затем запуститеgit fetch --pruneа потомgit gc

Я ищу «фатальный: плохой объект refs/remotes/origin/master» и передаю ссылку на этот вопрос о stackoverflow, чтобы найти ответ.

  • Моя ситуация
  1. git status
      zsh ❯ git status
On branch master
Your branch is based on 'origin/master', but the upstream is gone.
  (use "git branch --unset-upstream" to fixup)
  1. после того, как я выполнюgit branch --unset-upstream, я мог бы, но получил эту ошибку
      Unpacking objects: 100% (19/19), 6.82 KiB | 6.82 MiB/s, done.
fatal: bad object refs/remotes/origin/master
error: https://github.com/lapce/lapce-plugin-rust did not send all necessary objects
  • Попробуйте найти решение

следовать роковому массажу,

  1. , получил COMMIT-HASH
  2. cat .git/refs/remotes/origin/HEAD, получилref: refs/remotes/origin/master
  3. , там было пусто

возможно, файл.git/refs/remotes/origin/masterбыла проблема.

  1. rm .git/refs/remotes/origin/master, опять же, я получил,
         a9c3764..02d3a76  master     -> origin/master
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

    git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

    git branch --set-upstream-to=origin/<branch> master
  1. ОК, настроим обратно
      zsh ❯ git branch --set-upstream-to=origin/master master
branch 'master' set up to track 'origin/master'.
  1. пытаться
      zsh > git pull
Updating a9c3764..02d3a76
Fast-forward
 .gitignore      |   2 ++
 Cargo.lock      |  55 +++++++++++++++++++------------------------------------
 Cargo.toml      |   3 +--
 README.md       |   2 ++
 src/main.rs     |  89 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------------------------
 
...

 8 files changed, 88 insertions(+), 67 deletions(-)

Это выглядело нормально.

  1. cat .git/refs/remotes/origin/master,cat .git/refs/heads/master, получил тот же COMMIT-HASH.
  • Итак, наконец

В моем случае HEAD COMMIT-HASH в файле .git/refs/remotes/origin/master каким-то образом был пустым (git сказал вам, что восходящий поток пропал ). Удалите файл иgit pullснова, чтобы перестроить его, следуйте сообщению с советом git после каждого отзыва команды git, вероятно, все будет сделано.

Я удалил весь проект и вернул его обратно

В моем я просто удалил это конкретноеrefs:refs/heads/feat/implement-games. После этого я уже смогgit pull origin master

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

Мне помогло удаление дубликатов вручную. Я перешел к каждой из папок и вручную удалил дубликаты.

У меня была следующая проблема: плохие ссылки на объекты/теги/v1.0.1 2

  1. Откройте репо в терминале
  2. Перейдите в /tags с помощью команды cd.
  3. Запустите команду ls, чтобы убедиться, что дубликат существует, т.е. v1.0.1 2.
  4. Запустите команду rm, чтобы удалить дубликат -> rm v1.0.1\ 2 (\ для обработки пробела)

Затем попробуйте снова выполнить git gc. В моем случае в местах различий было больше дубликатов, которые мне пришлось удалить вручную таким же образом, но как только все были удалены, все заработало нормально.

Я надеюсь, что это сработает для вас!

Когда все остальные ответы не помогут, просто перезагрузите компьютер.

Я столкнулся с ошибкой OP, а также Permission denied на некоторых .gitattributeфайл в несвязанном каталоге (независимо от того, запущен ли он администратором или нет). Это мне помогло.

Другие вопросы по тегам