69

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
$
Lii
  • 11,553
  • 8
  • 64
  • 88
Max
  • 21,123
  • 5
  • 49
  • 71
  • 1
    [Follow the link here](http://stackoverflow.com/questions/5280212/git-error-on-branch-creation-warning-refname-master-is-ambiguous) – thar45 Sep 01 '12 at 04: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 Sep 01 '12 at 05:13
  • 1
    Do you have a tag named "master"? – Andy Ross Sep 01 '12 at 05: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-/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 May 07 '17 at 18:26

4 Answers4

90

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
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 9
    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 Sep 02 '12 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 Jan 15 '13 at 10:11
  • 2
    Thanks! So my fix was `git tag tag-master master ; git tag -d master` (This was also helpful: http://stackoverflow.com/questions/1028649/rename-a-tag-in-git) – Ashutosh Jindal Sep 24 '13 at 14:15
  • 1
    @AshutoshJindal Excellent! I have included your comment in the answer for more visibility. – VonC Sep 24 '13 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! – ShieldOfSalvation Dec 28 '22 at 21:18
  • @ShieldOfSalvation "release" is not a Git notion, but a GitHub or GitLab one. The OP is only about Git. You can wrap those commands in a script which will query your remote Git repositories hosting service and check if the deleted tag is part of a release (for example, for GitHub, with [`gh release view [tag]`](https://cli.github.com/manual/gh_release_view)). But that is out of scope for this question/answer. – VonC Dec 29 '22 at 15:52
43

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

Trebor Rude
  • 1,904
  • 1
  • 21
  • 31
  • 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 Sep 21 '16 at 19:23
  • Thank you! Your answer explained me what I was doing wrong. – VHS Jun 02 '20 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.

GaryO
  • 5,873
  • 1
  • 36
  • 61
  • 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 http://stackoverflow.com/questions/13073062/git-warning-refname-master-is-ambiguous/16302266#16302266 – Magnus Apr 30 '13 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 Mar 10 '17 at 07: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 Dec 08 '20 at 10:59
  • Apparently such files are called [pseudoref](https://git-scm.com/docs/gitglossary#def_pseudoref) — like .git/FETCH_HEAD etc. It's annoying that `update-ref foo/bar` [happily creates them](https://stackoverflow.com/questions/36006054/why-does-git-update-ref-accepts-non-refs-references) yet `update-ref -d foo/bar` will refuse to delete "bad name", need `rm`. – Beni Cherniavsky-Paskin Jun 20 '23 at 11:33
0

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/*

boryn
  • 726
  • 9
  • 10