git refname 'origin/master' is ambiguous

Question

I have a git repository that is tracking several remote branches:

$ git branch -a
* master
  remotes/git-svn
  remotes/origin/master
  remotes/trunk
<         


        

Answer 1

I faced same problem few days ago where there were multiple references created of the same branch.

Things i tried:

> git show-ref (will give you the list of references, from the
> references list you can check if there are multiple references created
> for the branch you are working on or not.)

If there are multiple references created then simply remove it

rm .git/refs/heads/master

After removing the references you can take the checkout of the branch from remote origin only if you have pushed something in it, otherwise you have to redo everything which you did in the branch

git fetch origin
git checkout origin/branchName

This solution worked out for me in case of ambiguous branches.

Answer 2

The output of git branch -a shows that you have a remote-tracking branch called origin/master. Perfectly normal.

However, the output of git show-ref master contains

6726b4985107e2ddc7539f95e1a6aba536d35bc6 refs/origin/master

which indicates that you most likely ran something like the following low-level command:

git update-ref refs/origin/master master

This command creates a branch (pointing at the same commit as master) called origin/master, but living directly under refs/, i.e. outside the refs/heads/ namespace, where local branches normally live. Quite suspicious... Did you mean to do that?

Such a branch won't get listed by git branch -a. Git is getting confused, though, because it sees two branches whose refnames end with origin/master:

• refs/remotes/origin/master, your remote-tracking branch, and
• refs/origin/master, the local branch that you created (by accident) outside refs/heads/.

Solution

If you did not mean to create refs/origin/master

Simply delete it:

git update-ref -d refs/origin/master

Then, there won't be any ambiguity, and Git will comply when you try to set master's upstream.

If you did mean to create refs/origin/master

To avoid ambiguity, simply specify the full refname of the branch you wish to set as master's upstream:

git branch --set-upstream-to=refs/remotes/origin/master master

---

To fix ideas, here is some code that reproduces the situation in one of my GitHub repos:

$ cd ~/Desktop
$ git clone https://github.com/Jubobs/gitdags && cd gitdags

$ git update-ref refs/origin/master

$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

$ git show-ref master
15b28ec22dfb072ff4369b35ef18df51bb55e900 refs/heads/master
15b28ec22dfb072ff4369b35ef18df51bb55e900 refs/origin/master
15b28ec22dfb072ff4369b35ef18df51bb55e900 refs/remotes/origin/HEAD
15b28ec22dfb072ff4369b35ef18df51bb55e900 refs/remotes/origin/master

$ git branch --set-upstream-to=origin/master master
warning: refname 'origin/master' is ambiguous.
fatal: Ambiguous object name: 'origin/master'.

$ git update-ref -d refs/origin/master
$ git branch --set-upstream-to=origin/master master
Branch master set up to track remote branch master from origin.

Answer 3

I had a very similar problem due to an accidental tag named "master", showing in git show-ref master as refs/tags/master. The fix in this case was:

git tag -d master

Answer 4

You probably accidentally created a local ref called 'origin/master'

for instance, if you did this

git branch origin/master

It would lead to this problem. This one looks suspect "refs/origin/master". "refs/heads/master" is your local master, "refs/remotes/origin/master" is your remote branch reference, and "refs/origin/master" is probably a mistake that is screwing you up.

You just need to delete that reference (git update-ref -d ) and things will start working again.