Why is "origin/HEAD" shown when running "git branch -r"?
Solution 1:
@robinst is correct.
In git, you can select which branch is checked out by default (i.e. when you clone). By default, origin/HEAD
will point at that.
On GitHub, You can change this in the Admin settings for your GitHub repo. You can also do it from the command-line via
git remote set-head origin trunk
or delete it altogether via
git remote set-head origin -d
Example. Look at the 'Switch Branches' drop-down. trunk
is checked, so origin/HEAD
follows trunk
.
Solution 2:
The reason a bare repository can have a HEAD, is that because it determines which branch is initially checked out after a clone of the repository.
Normally, HEAD points to master, and that is the branch that is checked out when people clone the repository. Setting it to another branch (by editing HEAD in the bare repository) results in that branch being checked out on clone.
Solution 3:
I was under the impression that dedicated remote repos (like GitHub where no one will ssh in and work on that code, but only pull or push, etc) didn't and shouldn't have a HEAD because there was, basically, no working copy. Not so?
I had the exact same impression like you said.
And I even can not delete that origin/HEAD remote-tracking branch cloned from github by doing
git branch -d -r origin/HEAD
This had no effect.
Can some one tell me how I can delete that origin/HEAD remote-tracking branch?
update
Though I did not found why there is a origin/HEAD created when clone from github, I find a way to delete it.
The new version of git provide
git remote set-head <name> -d
to delete the useless HEAD pointer of remote-tracking branch.
And we can also change the dumb default name 'origin' to whatever we want by using
git remote rename origin <new_name>
Hope this can help. :)
Solution 4:
You're right that pushing to dedicated remote repos work much better when they are 'bare', that is, when they don't have working directories. Git's architecture is designed for updating by patches or pull
(fetch
), which makes sense in a distributed VCS. As the docs say somewhere, pushing to a branch which is currently checked out can result in "unexpected results".
The HEAD is part of the requirements for a valid repository. Git Repository Layout says, in part:
HEAD
A symref (see glossary) to the refs/heads/ namespace describing the currently active
branch. It does not mean much if the repository is not associated with any working tree
(i.e. a bare repository), but a valid git repository must have the HEAD file; some
porcelains may use it to guess the designated "default" branch of the repository
(usually master). It is legal if the named branch name does not (yet) exist.
So you're going to see HEAD as part of the branch list, even if "it does not mean much..."