86

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

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

When I try to setup a default one I get the following error:

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

I would like to kremove some of the remote master branches but the master references are still there. How can I remove them to be able to set the default upstream branch to origin/master?

$ git show-ref master
cba97a58c99743c355b569bbf35636c8823c2d96 refs/heads/master
6726b4985107e2ddc7539f95e1a6aba536d35bc6 refs/origin/master
d83f025cd3800ed7acd76b2e52ae296e33f1cd07 refs/original/refs/heads/master
cba97a58c99743c355b569bbf35636c8823c2d96 refs/remotes/origin/master
jub0bs
  • 60,866
  • 25
  • 183
  • 186
gypaetus
  • 6,873
  • 3
  • 35
  • 45

6 Answers6

125

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.
jub0bs
  • 60,866
  • 25
  • 183
  • 186
  • related: http://stackoverflow.com/questions/948354/default-behavior-of-git-push-without-a-branch-specified `push.default` should be set to `upstream` (as `matching` will be ambiguous) – prusswan Sep 02 '16 at 06:15
  • 1
    thanks. Very well answered by explaining the cause, solution, and replicate the symptom. – soMuchToLearnAndShare Jul 03 '17 at 09:18
  • 1
    My issue was the same root cause but I must have gotten there a different way. The explanation was clear enough that I was able to adapt it to my situation. Well written explanation. There is a lot of technical writing on SO, some great and some not. This is great technical writing. – Matthew Poer May 28 '20 at 12:16
  • @MatthewPoer Thank you for your nice comment; I appreciate it. – jub0bs May 30 '20 at 07:26
  • could this be caused by having multiple similar branch args to git svn clone? (i.e. -b /branches/* -b branches/*/*)? – mike01010 Jun 20 '20 at 18:52
  • @mike01010 I'm not sure. Maybe. I'd have to test this. – jub0bs Jun 21 '20 at 06:05
  • 1
    @jub0bs - can confirm it does cause the issue – mike01010 Jun 21 '20 at 17:16
  • @mike01010 Very interesting! Feel free to add details in my answer or one of your own. – jub0bs Jun 21 '20 at 17:21
  • remove ref does work. But what is the cause? someone commit ambiguous refs to repo? – Maxi Wu Aug 19 '21 at 08:53
47

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.

Andrew C
  • 13,845
  • 6
  • 50
  • 57
9

I faced the same problem few days back 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.

Sumit Kapoor
  • 1,089
  • 12
  • 10
8

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
rymo
  • 3,285
  • 2
  • 36
  • 40
1

If the .git directory itself contains a ref called master, i.e. .git/master, you will see the same error message. The nasty issue here is that you won't get this ref reported by commands like git branch -a nor git show-ref master. (git version 2.30.0.windows.2)

mstrap
  • 16,808
  • 10
  • 56
  • 86
  • Helped me! This is similar to the accepted answer — a ref file stored outside `.git/refs/heads/` where local branches normally live — except when it's directly at top level outside `refs/`, even `git show-ref` won't list it :-(, and `update-ref -d` will refuse to delete "bad name", need `rm`. But `update-ref foo/bar` [happily creates one](https://stackoverflow.com/questions/36006054/why-does-git-update-ref-accepts-non-refs-references). Apparently these are called [pseudoref](https://git-scm.com/docs/gitglossary#def_pseudoref) — like .git/FETCH_HEAD etc. – Beni Cherniavsky-Paskin Jun 20 '23 at 11:27
0

Check your .git/config file. You may run into this problem if you have more than one remote repo configured with the same:

fetch = +refs/heads/*:refs/remotes/origin/*.

The other remote server should have a different name, eg.:

fetch = +refs/heads/*:refs/remotes/another_repo/*

boryn
  • 726
  • 9
  • 10