72

I've looked at all of the other ambiguous refname questions and none of them seem to help. Why am I getting this warning?

$ git checkout master
warning: refname 'master' is ambiguous.
$ git show-ref master
eef61c00da690f093063ac5a728e22fd21648104 refs/heads/master
$ git branch -a
  checkers
  exercises
* master
$ git remote -v
$ 
4
  • 1
    Follow the link here
    – thar45
    Commented Sep 1, 2012 at 4:09
  • As stated in my question, there is only one master branch and no remotes for this repo. The user in the question you linked to had a problem with a remote and a branch having the same name.
    – Max
    Commented Sep 1, 2012 at 5:13
  • 1
    Do you have a tag named "master"?
    – Andy Ross
    Commented Sep 1, 2012 at 5:30
  • A method of preventing this is to develop a convention in your codebase/org that ensures you never create overlapping refs. I use the following: For non-origin local branches use: local-<remote>/master. For release branches and tags, use something like release/1.x.x for release branches (i.e. git flow feature freeze) and release-tag/1.1.0 for tagging deployed/released code, and to disallow naming a branch release, release-tag or the name of an origin.
    – vaughan
    Commented May 7, 2017 at 18:26

4 Answers 4

92

TL;DR: save and delete the tag, as Ashutosh Jindal comments (see "Rename a tag in git?"):

git tag tag-master master
git tag -d master

Original answer:

Most of the sources I see (like this FAQ) point to the same cause:

When you try to checkout a local branch, you get a

warning: refname 'branch-name' is ambiguous

This can happen if you've created a local branch with the same name as a remote tag.
Git should be checking out your local branch, but instead it's trying to checkout the tag, and it gets confused.

The initial import of several trees were problematic, since they contained identically named branches and tags. We have since addressed a lot of these issues, by renaming away the tags.

In your case, you don't have a remote, but local tags named like your branch could be enough.

The ambiguity is specified in gitrevision

<refname>, e.g. master, heads/master, refs/heads/master

A symbolic ref name. E.g. master typically means the commit object referenced by refs/heads/master.
If you happen to have both heads/master and tags/master, you can explicitly say heads/master to tell git which one you mean.
When ambiguous, a <refname> is disambiguated by taking the first match in the following rules:

If $GIT_DIR/<refname> exists, that is what you mean (this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD and CHERRY_PICK_HEAD);

  • otherwise, refs/<refname> if it exists;
  • otherwise, refs/tags/<refname> if it exists;
  • otherwise, refs/heads/<refname> if it exists;
  • otherwise, refs/remotes/<refname> if it exists;
  • otherwise, refs/remotes/<refname>/HEAD if it exists.

So check where master can be found in your repo.

And git checkout heads/master would always work.
Warning: by default, this would checkout the branch in a DETACHED HEAD mode. See "Why does git checkout with explicit 'refs/heads/branch' give detached HEAD?".

To avoid that, and still use an unambiguous ref, type:

git checkout -B master heads/master
6
  • 10
    The search order for refs was helpful. $GIT_DIR/master did exist for some reason (no idea what it was pointing to or how it was created). Removing it fixed the warning.
    – Max
    Commented Sep 2, 2012 at 16:35
  • 1
    @Max, this was exactly my problem -- something made a .git/master file (whose contents was a hash, pointing at what the master used to be several revs ago) and renaming it fixed the warnings. Thanks!
    – Coderer
    Commented Jan 15, 2013 at 10:11
  • 2
    Thanks! So my fix was git tag tag-master master ; git tag -d master (This was also helpful: stackoverflow.com/questions/1028649/rename-a-tag-in-git) Commented Sep 24, 2013 at 14:15
  • 1
    @AshutoshJindal Excellent! I have included your comment in the answer for more visibility.
    – VonC
    Commented Sep 24, 2013 at 14:48
  • But what if that tag belonged to a release that we've already deployed? Deleting the tag would delete the release. I don't want that! Commented Dec 28, 2022 at 21:18
44

Although this doesn't apply to the OP's situation, I got myself a refname is ambiguous warning after accidentally doing a git branch origin/branch instead of a git checkout origin/branch. This created a local branch named origin/branch, which made it ambiguous with the remote branch. Solving the problem was as simple as git branch -D origin/branch (safe because -D operates on local branches).

2
  • This has happened to me more than once, the most frustrating and baffling symptom when I delete the master branch, yet it still shows up when doing git rev-parse master
    – Apeiron
    Commented Sep 21, 2016 at 19:23
  • Thank you! Your answer explained me what I was doing wrong.
    – VHS
    Commented Jun 2, 2020 at 18:30
25

This just happened to me. I somehow had a file .git/master containing a sha. Not sure how that got there, but when I deleted it, the error went away. If you read the accepted answer carefully, this is "expected behavior" but you won't see that .git/master if you do e.g. git show-ref master because it follows slightly different rules.

4
  • 19
    It is caused when you forget the "refs/heads" part of the update-ref command (well for me it was anyway). See my answer to stackoverflow.com/questions/13073062/…
    – Magnus
    Commented Apr 30, 2013 at 14:26
  • This was my issue. git checkout master loaded the branch correctly, git diff master staging used the ancient reference, which got confusing.
    – David Lord
    Commented Mar 10, 2017 at 7:10
  • This was the solution for me. Took me way too long to realize, I finally noticed it after running find .git -iname master
    – Link64
    Commented Dec 8, 2020 at 10:59
  • Apparently such files are called pseudoref — like .git/FETCH_HEAD etc. It's annoying that update-ref foo/bar happily creates them yet update-ref -d foo/bar will refuse to delete "bad name", need rm. Commented Jun 20, 2023 at 11:33
1

This message will appear as well if you had erroneously configured two remote servers with the same name which gives the ambiguity.

Check your .git/config file. If you have more than one remote repo configured with the same:

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

you should change one of them to a different name, eg.:

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.