предупреждение: удаленная ГОЛОВА относится к несуществующей ссылке, невозможно оформить заказ

86

Это похоже на популярную ошибку по разным причинам.

У меня есть простой репозиторий git под названием "kiflea.git", я клонирую его вот так:

git clone git://kipdola.be/kiflea.git

Тогда git говорит мне: warning: remote HEAD refers to nonexistent ref, unable to checkout.

И да, на карте нет версионных файлов, кроме каталога .git. В любом случае, единственное, что мне нужно сделать, это:

cd kiflea
git checkout master

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

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

[branch "master"]
    remote = origin
    merge = refs/heads/master

Вероятно, интересно знать, что этот репозиторий git в далеком прошлом был репозиторием svn.

Ps: при просмотре голого репозитория с помощью gitweb явно есть masterветка: http://kipdola.be/gitweb/?p=kiflea.git;a=summary

git скерит
источник
2
Что git ls-remote originвам показывает?
CB Bailey
checkout master25f600739343a7ce32d6311a1e6140870774810b refs/heads/master
То
1
Похоже, что удаленный репозиторий потерял (или никогда не имел) его HEAD. У вас есть к нему прямой доступ? Если да, то смотрите здесь
CB Bailey
1
Если вы клонируете репозиторий и не указываете ветку, он пытается использовать удаленную головку. Как объясняется ниже в ответах, вы не можете напрямую влиять на то, на какую ветку. Однако, проверяя другую ветку во время клонирования, вы избегаете этой проверки. В вашем случае кажется, что мастер существует, но удаленная голова указывает где-то еще, поэтому используйте:git clone -b master <url> <dir>
eckes

Ответы:

125

Это warning: remote HEAD refers to nonexistent ref, unable to checkout.означает, что удаленный (пустой) репозиторий содержит ссылку на ветку в названном файле HEAD, которая не соответствует ни одной опубликованной ветке в том же репозитории.

Обратите внимание, что предупреждение означает только то, что git не выполнил проверку. В остальном клонированный репозиторий вполне подойдет. Просто сделайте это, git branch -aчтобы увидеть возможные ответвления и решить git checkout the-branch-you-wantпроблему.

Обычно это происходит потому, что содержимое по умолчанию для этого файла ( .git/HEADили обычное HEADдля пустых репозиториев) ref: refs/heads/masterгласит, что если кто-то собирается в cloneэтот репозиторий, он должен по умолчанию клонировать ветку refs/heads/master. По умолчанию Git создаст локальную ветку без refs/heads/префикса (то есть masterпо умолчанию). Попробуйте получить git help symbolic-refдополнительную информацию.

Проблема с этой ситуацией заключается в том, что Git не предоставляет метод для изменения удаленных символических ссылок, поэтому либо вы используете то, что реализовал провайдер хостинга Git (например, Настройки - ветка по умолчанию в GitHub, если у вас есть права администратора), либо вы должны использовать имя ветки. masterкак ветвь по умолчанию (потому что это значение по умолчанию для этой символической ссылки).

Если у вас есть оболочка доступа к удаленному мерзавцу репо, вы можете просто cd path/to/bare/git/repo; git symbolic-ref HEAD refs/heads/XYZгде XYZэто название ветви вы хотите использовать по умолчанию.

Один из способов решить эту проблему - создать новое удаленное голое репо без коммитов, а затем сделать это, git push name-of-the-remote my-special-branch-nameчто приведет к голому репозиторию, содержащему одну ветвь, my-special-branch-nameно HEADсимволическая ссылка по-прежнему содержит значение по умолчанию, указывающее на master. В результате вы получите указанное выше предупреждение.

Микко Ранталайнен
источник
20
Обратите внимание, что предупреждение означает только то, что git этого не сделал checkout. В остальном клонированный репозиторий вполне подойдет. Сделайте это, git branch -aчтобы увидеть возможные ответвления и git checkout the-branch-you-want«исправить» проблему.
Mikko Rantalainen
2
По крайней мере, можно избежать использования удаленной головки при использовании git clone -b master(или любого другого имени существующей ветки).
eckes
Я сделал именно то, что вы написали в последнем абзаце; В ветке в голом репо (внутри gitlab) есть файлы, но клон кажется пустым. {git branch -a} ничего не показывает. {git clone -b my-special-branch-name <url>} тоже не работает (удаленный конец завис).
Эд Рэндалл
Я «исправил» это, скопировав refs / remotes / my-special-branch-name в refs / Head и отредактировав HEAD для соответствия (в голом репозитории gitlab). Затем я мог бы успешно клонировать, используя -b my-special-branch-name. Но как правильно настроить пустой пустой репозиторий после цикла "init" / "push", чтобы clone -b не столкнулся с проблемой?
Эд Рэндалл
1
@EdRandall, cd path/to/bare/git/repo; git symbolic-ref HEAD refs/heads/XYZгде XYZэто имя ветки по умолчанию, которое вы хотите использовать, если git cloneэто делается без -bфлага. Если у вас возникла другая проблема, задайте новый вопрос вместо того, чтобы добавлять вопросы в качестве комментариев.
Микко Ранталайнен,
10

У меня была такая же проблема, потому что я больше не использовал masterветку, и она потерялась как в моем локальном, так и в удаленном репозитории.

Удаленный репозиторий все еще был HEADустановлен master, я изменил его на одну из удаленных веток, которые я действительно использую, и все работает нормально.

Если у вас есть доступ к удаленному репозиторию:

  • Перейти к вашему remote_repo.git;
  • Редактировать HEADфайл
  • Изменить ref: refs/heads/masterнаref: refs/heads/your_branch
Марко Бонифази
источник
возможны оба условия, мастер был удален, а HEAD все еще указывает на него, или HEAD был изменен на ветвь, которая впоследствии была удалена. Полагаю (так как осмотр мастера работает) второй вариант - наш случай. @MarcoBonifazi В этом случае «изменение» было бы заменить broken_branchс refs/heads/master.
eckes
2
есть ли «правильный» способ установить ветку HEAD, не прибегая к редактированию файлов?
Эд Рэндалл
@EdRandall, cd path/to/bare/git/repo; git symbolic-ref HEAD refs/heads/XYZгде XYZэто имя ветки по умолчанию, которое вы хотите использовать, если git cloneэто делается без -bфлага, как я сказал в другом комментарии.
Микко Ранталайнен
7

Да, это связано с тем, что ваш клон git пытается проверить ветку, отличную от master. Просто сделай это

git clone user@git-server:project_name.git -b branch_name /some/folder

Это поможет вам клонировать точную ветку по ее имени.

pal4life
источник
2

Несмотря на то, что эта ошибка отображалась - мой проект все еще был подключен к соответствующему репозиторию - я запустил git branchкоманду и увидел соответствующие ветки - затем я запустил git checkout *branchnameи БУМ - все было хорошо.

реклама
источник
Да, @Mikko объяснила, в чем причина. Если вы хотите пропустить оформление заказа, вы можете использовать параметр -b. (Но в долгосрочной перспективе лучше исправить ваше удаленное репо!)
eckes
1

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

Джейсон Аксельсон
источник
Думаю, вы имели в виду: "git push -u origin HEAD: HEAD" Для меня это ничего не решило ...
RzR 07
1

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

Я могу просматривать веб-интерфейс репо, используя некоторые ссылки меню, но другие не работают с помощью 404 - Unknown commit objectили аналогичными, особенно со страницы сводки.

Посмотрите, можете ли вы изменить это последнее сообщение о фиксации, а затем принудительно нажмите на обновление, чтобы увидеть, исправляет ли это его. В демоне сервера может быть ошибка. Если это исправит, стоит сообщить о списке git git@vger.kernel.org (только текстовые сообщения)

Филип Окли
источник
1

У меня была такая же проблема при создании голого репо.

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

1) клонировать репо

$ git.exe clone --progress -v "the remote path" "my local path"

2) локально создать главную ветку.

   $ git checkout -b master

3) совершить что-то в локальной ветке

$ git add readme.md 
$ git commit –m “Added readme”

4) Нажимаем локальный мастер на удаленном

   $ git push origin master
Коррадо
источник
0

Если на самом деле нет основной доступной ветки, проверьте следующее; Если внутри папки .git есть файл с именем «pack-refs», откройте его, и вы сможете найти все перечисленные ссылки.

Что-то вроде ниже;

# pack-refs with: peeled fully-peeled 
e7cc58650190bd28599d81917f1706445d3c6d8b refs/tags/afw-test-harness-1.5
^cfae4f034e82591afdf4e5ed72279297d0eee618
6afe1bcfa4bd74de8e0c8f64d024e1cc289206df refs/tags/afw-test-harness-2.1
^c32f7fa495d4b44652f46c065fcd19c3acd237a6
72f2e4284dfbf27c82967da096c6664646bbdd19 refs/tags/android-1.6_r1
^50992e805e758e2231f28ec2127b57a1a9fd0ddc
0cbd528cad1cee9556098b62add993fc3b5dcc33 refs/tags/android-1.6_r1.1

Затем используйте;

git checkout refs/tags/xxxx

Или 

git checkout 'HASH value'

чтобы проверить нужную версию. Спасибо.

Саманта
источник
0

Я вроде исправил это с помощью:

git checkout -b  master
git push

Это создало мастер по умолчанию, а затем я мог проверить свои другие ветки

Брендан
источник
0

В моем случае репо было пустым.

git checkout --orphan master

git add some_file
git commit -m 'init'
git push origin master
Ласло Тот
источник
0

Для Gitlab, даже если он показывает, что вы находитесь в ветке по умолчанию (например master), вы на самом деле можете не быть в ней, установив ее снова, исправьте это, например:

  1. Создать новую ветку, возможно asd
  2. настройки> репозиторий> ветка по умолчанию, которая показывает, что ветка по умолчанию master
  3. Установите это на asd
  4. Установите обратно на master
  5. Удалить asdветку

Готово, теперь ваша ветка по умолчанию master

Нг Сек Лонг
источник