Why is "origin/HEAD" shown when running "git branch -r"?

Ben_Hamill_9619 0
Viewed 69486

When you run git branch -r why the blazes does it list origin/HEAD? For example, there's a remote repo on GitHub, say, with two branches: master and awesome-feature. If I do git clone to grab it and then go into my new directory and list the branches, I see this:

$ git branch -r
origin/HEAD
origin/master
origin/awesome-feature

Or whatever order it would be in (alpha? I'm faking this example to keep the identity of an innocent repo secret). So what's the HEAD business? Is it what the last person to push had their HEAD pointed at when they pushed? Won't that always be whatever it was they pushed? HEADs move around... why do I care what someone's HEAD pointed at on another machine?

I'm just getting a handle on remote tracking and such, so this is one lingering confusion. Thanks!

EDIT: 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?

version-control github git
7 Answers

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. :)

user_1477150

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..."

Paul_233560

There's always a HEAD that points to the currently checked out branch on the remote repo (which may or may not be master). Even remote repositories have current branches. Usually it is master, and off the top of my head I can't think of any reason why one would want to change it, but it can be changed.

codelogic_434270

My guess is that someone pushed a branch and called it HEAD:

git push origin HEAD
Dustin_399750
Related