Почему нет пультов/origin/HEAD -> origin/master для новой ветки, которую я нажал на репо

Question

Я создал ветвь git и нажал ее на исходный мастер. Сейчас, когда я делаю git branch --all, он не показывает мне remotes/origin/HEAD --> origin/master. Тем не менее, я могу выполнять все операции git.

• Ожидается ли это?
• Какова логика наличия/отсутствия записи ?

Edit:

Похоже, существует некоторая путаница в том, что я на самом деле. Я импортировал репо от p4 Вот последовательность:

1. git init 
2. ../git/git-p4.py clone --detect-branches //projects/<my_project_path_in_p4> 
3. git checkout -q -b master refs/remotes/p4/<my_project_path> 
4. git add --all 
5. git commit -m "Initial Commit" 
6. git remote add origin <my_git_path> 
7. git push origin master 

, а затем, когда я делать GIT ветви --all я не вижу, что конкретной записи:

* master 
remotes/origin/master 
remotes/p4/workflow_manager/workflow_manager-15.3.0 

** Во-вторых Edit: **

Когда я клонировать ту же ветку и сделать git branch --all я remotes/origin/HEAD --> origin/master. Вот результат после клонирования, который, как ожидается,

* master 
remotes/origin/HEAD -> origin/master 
remotes/origin/master 

Так что теперь я еще больше запутался :)

Answer 1

Почему remotes/origin/HEAD не хватает?

Вы могли бы удалить его с вашего устройства через git remote set-head -d origin. Похоже, ты этого не делал.

Как его вернуть?

В любом случае, вы можете вернуть его, запустив git remote set-head -a. Это попросит удаленный элемент определить его HEAD, а затем обновит ваш локальный адрес соответствующим образом.

Ожидаемый недостаток HEAD?

Нет, этого не ожидается.

Зачем нам remotes/origin/HEAD?

remotes\origin\HEAD указывает на разницу по умолчанию на пульте дистанционного управления. Логика заключается в том, что вы можете использовать origin в качестве сокращения, когда бы вы в противном случае не использовали origin/master. Например. он составляет git log origin/master, эквивалентный git log origin.

Смотрите также

https://www.kernel.org/pub/software/scm/git/docs/git-remote.html

Answer 2

Есть два способа сделать GIT-p4 обнаружить ветви:

1. Есть спецификации филиалов, определенные в P4 сервере, которые позволяют ГИТ-p4, чтобы определить возможные переделах в структуре каталогов.
2. Используйте git config --local git-p4.branchList path/to/branchA:path/to/branchB, чтобы определения ветвлений были локальными в вашем хранилище git.

Получение второй вариант права иногда бывает трудно, но после вашего примера, я думаю, что вы должны начать с добавлением следующей конфигурации:

git config --local git-p4.branchList workflow_manager/workflow_manager-15.3.0:workflow_manager/workflow_manager-15.3.0 

Пожалуйста, обратите внимание, что в моем личном опыте, я всегда начинал путем импорта репозитория P4, который уже содержит ветви. То есть все работы по инициализации выполнялись непосредственно под P4. Я предлагаю вам сделать то же самое. Но учтите, что для правильного обнаружения филиалов вам необходимо импортировать всю историю с использованием нотации @all в конце пути репозитория P4.

Альтернативой может быть использование временного репозитория git без обнаружения ветвления для инициализации сервера P4, а затем использовать P4 для интеграции/копирования/ветвления из начальной ветви в новую. На этом этапе вы должны иметь возможность правильно импортировать репозиторий P4 в новый репозиторий git с использованием обнаружения ветвей и конфигураций, описанных выше.