Git не удается разрешить ссылки при нажатии

У меня проблема с Git. По неизвестным причинам моя главная ветвь каким-то образом испортилась. У меня есть локальная фиксация, которую я хочу нажать, но когда я нажимаю, я получаю следующее:

git push origin master
error: unable to resolve reference refs/remotes/origin/master: No such file or directory
error: cannot lock the ref 'refs/remotes/origin/master'.
Everything up-to-date

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

  • Исправлено изменение моей текущей фиксации и нажатие
  • очистил мой репозиторий git с помощью git gc --prune=now
  • Пробовал rm .git/refs/removes/origin/master

Никто не решил мои проблемы. Любые мысли или идеи?

Ответы

Ответ 1

(стоящий tl; dr из @NeTeInStEiN:

Ядерная опция rm -rf .git/refs/remotes/origin, и что она здесь взяла)

edit: Я столкнулся с частью этого поведения в одном из своих собственных репозиториев, я могу получить git, чтобы воспроизвести сбой f-e-r без rm .git/refs/remotes/origin/master hack:

  • клонировать репо
  • удалить начальную ветвь происхождения (к которой привязан ее HEAD)
  • запустите git fetch --prune в клоне

Извлечение будет выдавать предупреждение об ошибке, и git for-each-ref завершится неудачно с знакомым сообщением:

~/sandbox/20/buddy$ git fetch --prune
From /home/jthill/sandbox/20/source/.
 x [deleted]         (none)     -> origin/master
   (refs/remotes/origin/HEAD has become dangling)
~/sandbox/20/buddy$ git f-e-r
fatal: missing object 0000000000000000000000000000000000000000 for refs/remotes/origin/HEAD

но это не разрушает нажатие, я пробовал с каждой настройкой push.default и не разбивал git update-ref -d.

Тем не менее, googling push-сообщение получило мне следующее:

Я только что перезагрузился с BSOD на днях [...], затем git push. И вот когда я получил жалобу о "Не удалось разрешить ссылки refs/remotes/origin/master..." . [...] Итак, я открыл мастер файл, и он был заполнен пробелами! Ну, это нехорошо. Чтобы исправить это, я сделал следующее: [ваш rm, а затем git fetch]

См. комментарии выше для "blow-by-blow" , tl; dr, потому что это были удаленные ссылки, которые git fetch полностью обновляется, а также потому, что ущерб был таким, что for-each-ref и git update-ref не удалось вообще работать, ядерная опция rm -rf refs/remotes/origin; git fetch гарантировала бы правильное восстановление пульта.

В других случаях, если бы не было простого способа восстановить поврежденные ссылки или любопытство, find .git/refs/remotes/origin -type f для проверки блокировок или использования журналов (эти файлы находятся в .git/logs), чтобы восстановить содержимое, помогло бы, но здесь не было необходимости. Я думаю, что я пропустил ставку, не сделав здесь find первых, *.lock файлов из более ранней команды kill -9 ed, вероятно, здесь, но я подозревал, что для них первый двусмысленный реф и f-e-r.

Ответ 2

Примечание: с Git 2.5 (июль 2015 г.) git for-each-ref будет немного более точным, если он не пройдет с "отсутствующим объект".

См. commit 501cf47, commit f551707 (03 июня 2015) и commit 8afc493, совершить c3e23dc ​​ (02 июня 2015) Майкл Хаггерти (mhagger).
(слияние Junio ​​C Hamano - gitster - в commit 9d71c5f, 24 июня 2015 г.)

for-each-ref: правильно сообщать о неправильных ссылках

Если есть свободный файл ссылки с недопустимым содержимым, "git for-each-ref" неправильно сообщает о проблеме как о пропавшем без вести объект с именем NULL_SHA1:

$ echo '12345678' >.git/refs/heads/nonsense
$ git for-each-ref
fatal: missing object 0000000000000000000000000000000000000000 for refs/heads/nonsense

С явной строкой "--format" она даже может сообщить, что ссылка действительно указывает на NULL_SHA1:

$ git for-each-ref --format='%(objectname) %(refname)'
0000000000000000000000000000000000000000 refs/heads/nonsense
$ echo $?
0

NULL_SHA1 используется для обозначения "invalid object name" на протяжении всего нашего кода (и кода других реализаций Git), поэтому значительно больше вероятно, что ссылка на диске была установлена ​​на это значение из-за ошибка программного обеспечения, чем это NULL_SHA1 является законным SHA-1 фактического объект.
Следовательно, если свободная ссылка имеет значение NULL_SHA1, считайте его сломанным.