Our repo happens to have a tag that has the same name as the branch name. So when I try to pull from that branch, git confused and pulled from tag, like this. I have to delete that tag first to make my git pull work.
So how do I tell git pull from branch not from tag ?
cc-backend ➤ git pull origin 0.9.0-rc6-patch1
From 10.0.0.28:webcc/cc-backend
* tag 0.9.0-rc6-patch1 -> FETCH_HEAD
Already up to date.
/* I have to delete that tag and git pull again to get the result I want */
cc-backend ➤ git pull origin 0.9.0-rc6-patch1
From 10.0.0.28:webcc/cc-backend
* branch 0.9.0-rc6-patch1 -> FETCH_HEAD
Updating 9d7e9dc3..2bf3f96a
Fast-forward
app/Services/GroupSeat/Seat.php | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
It seems the remote repository has a tag and a branch with the same name 0.9.0-rc6-patch1. Use the full name to fetch/pull,
# fetch/pull the tag
git fetch/pull origin refs/tags/0.9.0-rc6-patch1
# fetch/pull the branch
git fetch/pull origin refs/heads/0.9.0-rc6-patch1
There could be other refs. According to my personal experience, a Gerrit user may push and create an unexpected ref in a Gitlab repository by mistakenly following the Gerrit push syntax git push origin HEAD:refs/for/master. refs/for/master is a client magic ref. After receiving this push, Gerrit converts it into a pending change ref like refs/changes/11/2311/1 in the server side and binds it with the target branch master. When this change is approved, this ref will be merged into refs/heads/master. However, Gitlab simply creates a meaningless ref refs/for/master. In some cases, later the user may fail to update the local master branch with the head always pointing to an older commit, although the git pull command succeeds.
If you encounter this abnormal behavior, use git ls-remote | grep master to check if there are any refs of the same name. A privileged user can delete refs/for/master by git push origin :refs/for/master or git push $remote_url :refs/for/master.