git clone - default branch

Question

After cloning a git repository from my gitlab server, it does not checkout master, as origin/HEAD points to some other branch 'origin/foo'. In gitlab, the default branch is set to master.

How can I move origin/HEAD from 'origin/foo' to point to 'origin/master', so that further clones automatically check out origin/master?

Right after cloning, git remote show origin states:

HEAD branch: foo

git remote -r seconds that:

origin/HEAD -> origin/foo

---

I want the HEAD branch to point to master, though - inside gitlab - the default branch is already set to master.

Answer 1

This can be done only server-side. For GitLab, it is done in your project, Settings (last item in the sidebar on the left), "Default Branch" (third text field).

Apparently there is an issue at the moment (March 2016) which means that the default branch reported by GitLab is not always the same as the HEAD branch reported by git remote show origin . Setting the GitLab default branch to anything else, then setting it back to master, has worked for @rralf.

Answer 2

Besides Paul Hicks' answer , it's worth adding that if your client-side git is very old (that is, predating 1.8.5, although the fix was back-ported to 1.8.4.3 as well), it may not choose the correct branch anyway.

The problem occurs when the server's HEAD reference resolves to a commit ID that is also the tip of more than one branch. The clone process, on these old versions of git, is not able to understand the HEAD -> ... direction and instead just gets the raw commit ID to which HEAD resolves. It also gets the commit IDs for each branch, and then it picks some branch—which one is essentially random—that has that commit ID.

Newer clients negotiate the symbolic style transfer, and get the correct branch every time. If you are stuck with an old one, though, one workaround is to make sure that the ID to which HEAD resolves is associated with only one branch. That is, for each other branch that matches, make a dummy commit so that the tip of that branch is no longer the same ID.

(This also fails if the server is too old, since those old servers don't accept the symbolic transfer option during the negotiation phase, but of course GitLab is not stuck in the last decade like certain Linux distributions that we won't CentOname, ahem.)

Answer 3

For this question, you need to operate on remote side, i think. Doing something like:

git checkout master.

to let HEAD refer to master.