Posted By: Anonymous
I have a branch set up to track a ref in origin.
git checkout <branchname> switches to that branch, and a
git status will show me how far ahead or behind my branch is from origin, but I’m surprised that
origin/HEAD still points at
origin/master, and not
So my question is, under what circumstances does origin/HEAD get moved?
I appreciate the answers about how to move origin/HEAD, but I’m interested in what “organically” moves it, outside of me explicitly telling it to do so.
For example, when I switch branches, git makes HEAD point at the branch I’m checking out, so I’m surprised that origin/HEAD doesn’t move in the same manner.
Note first that your question shows a bit of misunderstanding. origin/HEAD represents the default branch on the remote, i.e. the HEAD that’s in that remote repository you’re calling origin. When you switch branches in your repo, you’re not affecting that. The same is true for remote branches; you might have
origin/master in your repo, where
origin/master represents a local copy of the
master branch in the remote repository.
origin’s HEAD will only change if you or someone else actually changes it in the remote repository, which should basically never happen – you want the default branch a public repo to stay constant, on the stable branch (probably master). origin/HEAD is a local ref representing a local copy of the HEAD in the remote repository. (Its full name is refs/remotes/origin/HEAD.)
I think the above answers what you actually wanted to know, but to go ahead and answer the question you explicitly asked… origin/HEAD is set automatically when you clone a repository, and that’s about it. Bizarrely, that it’s not set by commands like
git remote update – I believe the only way it will change is if you manually change it. (By change I mean point to a different branch; obviously the commit it points to changes if that branch changes, which might happen on fetch/pull/remote update.)
Edit: The problem discussed below was corrected in Git 188.8.131.52; see this update.
There is a tiny caveat, though. HEAD is a symbolic ref, pointing to a branch instead of directly to a commit, but the git remote transfer protocols only report commits for refs. So Git knows the SHA1 of the commit pointed to by HEAD and all other refs; it then has to deduce the value of HEAD by finding a branch that points to the same commit. This means that if two branches happen to point there, it’s ambiguous. (I believe it picks master if possible, then falls back to first alphabetically.) You’ll see this reported in the output of
git remote show origin:
$ git remote show origin * remote origin Fetch URL: ... Push URL: ... HEAD branch (remote HEAD is ambiguous, may be one of the following): foo master
Oddly, although the notion of HEAD printed this way will change if things change on the remote (e.g. if foo is removed), it doesn’t actually update
refs/remotes/origin/HEAD. This can lead to really odd situations. Say that in the above example origin/HEAD actually pointed to foo, and origin’s foo branch was then removed. We can then do this:
$ git remote show origin ... HEAD branch: master $ git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/foo $ git remote update --prune origin Fetching origin x [deleted] (none) -> origin/foo (refs/remotes/origin/HEAD has become dangling)
So even though remote show knows HEAD is master, it doesn’t update anything. The stale foo branch is correctly pruned, and HEAD becomes dangling (pointing to a nonexistent branch), and it still doesn’t update it to point to master. If you want to fix this, use
git remote set-head origin -a, which automatically determines origin’s HEAD as above, and then actually sets origin/HEAD to point to the appropriate remote branch.