Error failed to run repack

Сегодня я случайно наткнулся на это, пытаясь запустить Git сборщик мусора:

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

Как мне с этим справиться?

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

$ 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-репо

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

Исправлю это

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

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

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

git update-ref -d [wrong reference here]

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

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

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

Если вы получаете ошибку с .git, как показано ниже:

error: bad ref for .git/logs/refs/remotes/origin/Dec/session-dynatrace-logs 6

Вы можете скопировать путь, начинающийся с refs, как показано ниже:

git update-ref -d 'refs/remotes/origin/Dec/session-dynatrace-logs 6'

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

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

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

git касса главная
// Я удалил файл .gitrefsheadsbranch_xpto
git тянуть
git checkout branch_xpto

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

cat .git/refs/remotes/origin/HEAD

Возвращается :

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, убедитесь, что вы делаете

git worktree prune

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

git gc

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