git clone – default branch

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?

  • git post-commit hooks
  • How do I create a duplicate remote branch, local branch and start checking in new changes?
  • Using passworded git in cruisecontrol.NET
  • fatal: Not a git repository (or any of the parent directories): .git on every rails command but git commands works fine
  • undo git pull in a rails app
  • Using .gitignore to ignore everything but specific directories
  • 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.

  • How do I cleanup Git Commits messed up by Rebase
  • Config git server: "fatal: '/C/Users/khanh/test.git' does not appear to be a git repository
  • I wish I'd branched in Git - can I turn back time?
  • Why Does My BASH Script Fail When Adding Additional Arguments?
  • How I can restore missed commits?
  • What is the practical difference between `git rm --cached`, `git reset --` and `git reset HEAD` to unstage changes?
  • 3 Solutions collect form web for “git clone – default branch”

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

    Screenshot of GitLab Project Settings page

    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.

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

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

    git checkout master.

    to let HEAD refer to master.

    Git Baby is a git and github fan, let's start git clone.