为什么没有遥控器/起源/头部 - >我推动回购的新分店的起源/主人

Why there is no remotes/origin/HEAD --> origin/master for a new branch which I pushed to repo

I created a git branch and pushed it to origin master. Now when I do git branch --all it does not show me remotes/origin/HEAD --> origin/master. I am able to perform all the git operations though.

  • Is this expected?
  • What is the logic behind having/not having this entry?

Edit:

Looks like there is some confusion in what I actually did. I imported a repo from p4 Here is the sequence:

 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

and then when i do git branch --all i don't see that particular entry:

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

** Second Edit:**

When I clone the same branch and do git branch --all I get remotes/origin/HEAD --> origin/master. Here is the output after cloning which is expected

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

So now I am even more confused :)

Why is remotes/origin/HEAD missing?

You could have deleted it from your machine via git remote set-head -d origin. It sounds like you didn't do that.

How do I get it back?

In any case, you can get it back by running git remote set-head -a. This asks the remote to determine its HEAD and then updates your local appropriately.

Is a missing remote HEAD expected?

No, that's not expected.

Why would we have remotes/origin/HEAD?

remotes\origin\HEAD indicates the default branch on the remote. The logic is that you can then use origin as a shorthand whenever you would otherwise use origin/master. E.g. it makes git log origin/master equivalent to git log origin.

See Also

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

added more details

There are two ways to make git-p4 detect branches:

  1. Have branch specifications defined in your P4 server that allow git-p4 to determine possible repartitions in the directory structure.
  2. Use git config --local git-p4.branchList path/to/branchA:path/to/branchB to have the branch definitions local to your git repository.

Getting the second option right is sometimes difficult, but following your example I think that you should start by adding the following configuration:

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

Please note that in my personal experience I've always started by importing a P4 repository that already contained branches. That is, all the initialization work was done directly under P4. I suggest that you do the same. But take into consideration that for the branches to be correctly detected you need to import the complete history using the @all notation at the end of the P4 repository path.

An alternative would be to use a temporary git repository without branch detection for the initialization of the P4 server, then use P4 to integrate/copy/branch from the initial branch to the new one. At this point you should be able to correctly import the P4 repository to a new git repository using branch detection and the configurations I described above.