попередження: віддалений HEAD відноситься до неіснуючого посилання, неможливе оформлення замовлення

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як гілка за замовчуванням (оскільки це значення за замовчуванням для цього символічного посилання).

Якщо у вас є доступ до оболонки до вашого віддаленого репозиторію git, ви можете просто вказати, 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"виправити" проблему.
— Мікко Ранталайнен,
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 / heads та відредагувавши 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
— Марко Боніфазі
джерело
можливі обидві умови, master був видалений, а 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і BOOM - все було добре.

— adswebwork
джерело
Так, @Mikko пояснив, в чому причина. Якщо ви хочете пропустити оплату, ви можете скористатися опцією -b. (Але краще виправити віддалене репо в довгостроковій перспективі!)
— eckes
1

З вашим віддаленим сховищем, безумовно, щось не так. Можливо, ви зможете це виправити, створивши новий клон сховища. Також надсилання нового коміту до гілки master може також спрацювати.

— Джейсон Аксельсон
джерело
Думаю, ви мали на увазі: "git push -u origin HEAD: HEAD" Це нічого не вирішило для мене ...
— RzR
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 є файл із назвою 'packed-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

— Нг Сек Лонг
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.