Як поводитися з git gc fatal: погані відхилення об'єктів / видалення / походження / помилка HEAD?

131

Я випадково потрапив на це сьогодні, намагаючись запустити Git- збирання сміття :

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

Як я маю справу з цим?

— Райан
джерело

163

Я не розумію наслідків цього, але, як це запропоновано в цій темі , коли я стикався з цим, я просто робив це

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

(тримати його на всякий випадок) і потім

$ git gc

працювали, не нарікаючи; Я не стикався з жодними проблемами.

— петрельхарп
джерело

6

Це працювало для мене, і я думаю, що я потрапив у цю проблему, тому що я змінив гілку за замовчуванням masterна іншу, що називається develop. За кілька днів до того, як я поверну його назад developдо, masterі я видалив стару гілку за замовчуваннямdevelop , але в моєму робочому каталозі файл .git/refs/remotes/origin/HEADвсе ще вказував на refs/remotes/origin/developякий більше не існує. У цій ситуації видалення файлу спрацювало.

— Ставаренго

4

git pruneпрацював для мене, спосіб видалити дані, накопичені в Git, але на які не посилається нічого корисного.

— Свен Малвік

Виконання їх вирішило мою проблему:$ mv .git/refs/remotes/origin/HEAD /tmp $ git gc git prune

— Девід Раука

2

Я підозрюю , що найкраще було б @ відповідь WilQu в ( stackoverflow.com/a/49944297/660339 ). Хтось може це підтвердити?

— Іван Перес

видалення цих файлів із папки .git, ніж git gcпрацювало для мене

— Vino

68

Проблема, з якою я зіткнувся (це та сама проблема, про яку згадував @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

— Трентон
джерело

1

Це було і моє виправлення

— Ден Карлстедт

1

Це було моє точне рішення. Нещодавно наша команда змінилася з використання гілки за замовчуванням, щоб розвиватися і майстрами

— jmancherje

40

Побачивши відповідь Трентона, я подивився на мою .git/refs/remotes/origin/HEADі побачив, що вона також вказує на стару гілку, яку тепер видалено.

Але замість редагування файлу я спробував рішення Райана:

git remote set-head origin --auto

Він автоматично встановив файл у нову гілку, і git gcдобре працював після цього.

— WilQu
джерело

Так, це працює для мене - як і я був за точно таким же сценарієм. git remote set-head $REMOTE --autoу моєму випадку $ REMOTE - це віддалений псевдонім, а не "початкове" за замовчуванням, оскільки у мене є кілька віддалених налаштувань.

— Devy

29

Я думав, що рішення було таким, оскільки це, здавалося, спрацювало, але виявляється, що насправді не вирішує проблему.

git remote set-head origin --auto

— Райан
джерело

1

Схоже, ця команда допомогла мені позбутися тієї ж неприємності. Однак після цієї команди я також використовував git prune(як це було рекомендовано у першому виведенні команди), тому я не в змозі точно сказати, що мені допомогло - перше, друге чи те й інше.

— Borys Pylhun

1

git remote set-head origin --autoвиправили мої реф. / видалення / походження / HEAD файл, не використовуючи менеgit prune

— danio

Я зіткнувся з цією помилкою: error: Multiple remote HEAD branches. Please choose one explicitlyі мені довелося скористатися git remote set-head origin mybranch(поки відділення "mybranch" виходило з каси), щоб помилка вийшла з ладу.

— derekmx271

3

Відхилення, оскільки це не є повною відповіддю і може ввести в оману.

— Крістіан Вільма

9

Схоже, ваші символічні відмови можуть бути зламані ... Спробуйте замінити його на вашу гілку за замовчуванням так: Наприклад, моя гілка за замовчуванням є головним

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

Це повинно це виправити.

— Conal Trinitrotoluene Da Costa
джерело

0

Якщо ви використовуєте git worktrees, переконайтеся, що ви робите

git worktree prune

перед бігом

git gc

У мене було пошкоджене робоче дерево, і це, здавалося, зробило трюк після видалення зіпсованого робочого дерева. git pruneсам по собі, здавалося, не працює.

— JeffP
джерело

0

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

Єдиним виправленням було стерти робочий каталог та знову клонувати репо-дистанційні (-и). На щастя, я все-таки могла натискати та витягувати оновлення, щоб нічого не втрачено. Зараз все добре.

— Буде Строль
джерело