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