Your configuration specifies to merge with the <branch name> from the remote, but no such ref was fetched.?
Solution 1
What this means
Your upstream—the remote you call origin
—no longer has, or maybe never had (it's impossible to tell from this information alone) a branch named feature/Sprint4/ABC-123-Branch
. There's one particularly common reason for that: someone (probably not you, or you'd remember) deleted the branch in that other Git repository.
What to do
This depends on what you want. See the discussion section below. You can:
- create or re-create the branch on the remote, or
- delete your local branch, or
- anything else you can think of.
Discussion
You must be running git pull
(if you were running git merge
you would get a different error message or no error message at all).
When you run git fetch
, your Git contacts another Git, based on the url
line under the [remote "origin"]
section of your configuration. That Git runs a command (upload-pack
) that, among other things, sends your Git a list of all branches. You can use git ls-remote
to see how this works (try it, it is educational). Here is a snippet of what I get when running this on a Git repository for git
itself:
$ git ls-remote origin
From [url]
bbc61680168542cf6fd3ae637bde395c73b76f0f HEAD
60115f54bda3a127ed3cc8ffc6ab6c771cbceb1b refs/heads/maint
bbc61680168542cf6fd3ae637bde395c73b76f0f refs/heads/master
5ace31314f460db9aef2f1e2e1bd58016b1541f1 refs/heads/next
9e085c5399f8c1883cc8cdf175b107a4959d8fa6 refs/heads/pu
dd9985bd6dca5602cb461c4b4987466fa2f31638 refs/heads/todo
[snip]
The refs/heads/
entries list all of the branches that exist on the remote,1 along with the corresponding commit IDs (for refs/tags/
entries the IDs may point to tag objects rather than commits).
Your Git takes each of these branch names and changes it according to the fetch
line(s) in that same remote
section. In this case, your Git replaces refs/heads/master
with refs/remotes/origin/master
, for instance. Your Git does this with every branch name that comes across.
It also records the original names in the special file FETCH_HEAD
(you can see this file if you peek into your own .git
directory). This file saves the fetched names and IDs.
The git pull
command is meant as a convenience short-cut: it runs git fetch
on the appropriate remote, and then git merge
(or, if so instructed, git rebase
) with whatever arguments are needed to merge (or rebase) as directed by the [branch ...]
section. In this case, your [branch "feature/Sprint4/ABC-123-Branch"]
section says to fetch from origin
, then merge with whatever ID was found under the name refs/heads/feature/Sprint4/ABC-123-Branch
.
Since nothing was found under that name, git pull
complains and stops.
If you run this as two separate steps, git fetch
and then git merge
(or git rebase
), your Git would look at your cached remotes/origin/
remote-tracking branches to see what to merge with or rebase onto. If there was such a branch at one time, you may still have the remote-tracking branch. In this case, you would not get an error message. If there was never such a branch, or if you have run git fetch
with --prune
(which removes dead remote-tracking branches), so that you have no corresponding remote-tracking branch, you would get a complaint, but it would refer to origin/feature/Sprint4/ABC-123-Branch
instead.
In either case, we can conclude that feature/Sprint4/ABC-123-Branch
does not exist now on the remote named origin
.
It probably did exist at one time, and you probably created your local branch from the remote-tracking branch. If so, you probably still have the remote-tracking branch. You might investigate to see who removed the branch from the remote, and why, or you might just push something to re-create it, or delete your remote-tracking branch and/or your local branch.
1Well, all that it is going to admit to, at least. But unless they have specifically hidden some refs, the list includes everything.
Edit, Jul 2020: There's a new fetch protocol that can avoid listing everything, and only list names that your Git says it's looking for. This can help with repositories that have huge numbers of branches and/or tags. However, if your Git is interested in all possible names, you'll still get all the names here.
Solution 2
This can also happen if you/someone renamed the branch.
So follow these steps (if you know that branch name is renamed)
Assuming earlier branch name as wrong-branch-name
and someone renamed it to correct-branch-name
So.
git checkout correct-branch-name
git pull
(you'll see this "Your configuration specifies..")
git branch --unset-upstream
git branch --set-upstream-to=origin/correct-branch-name
for older git versions git push --set-upstream origin correct-branch-name
git pull
(you'll not get the earlier message )
Solution 3
Check if your remote branch is available to pull. I had the same issue, finally realized the remote branch was deleted by someone.
Solution 4
This is a more common error now as many projects are moving their master
branch to another name like main
, primary
, default
, root
, reference
, latest
, etc, as discussed at Github plans to replace racially insensitive terms like ‘master’ and ‘whitelist’.
To fix it, first find out what the project is now using, which you can find via their github, gitlab or other git server.
Then do this to capture the current configuration:
$ git branch -vv
...
* master 968695b [origin/master] Track which contest a ballot was sampled for (#629)
...
Find the line describing the master
branch, and note whether the remote repo is called origin
, upstream
or whatever.
Then using that information, change the branch name to the new one, e.g. if it says you're currently tracking origin/master
, substitute main
:
git branch master --set-upstream-to origin/main
You can also rename your own branch to avoid future confusion:
git branch -m main
Solution 5
For me it was a case sensitivity issue. My local branch was Version_feature2 instead of Version_Feature2. I re-checked out my branch using the correct casing and then git pull worked.
Farrukh Chishti
Looking for jobs as Java or Hybris developer. Please contact me at- [email protected]
Updated on July 08, 2022Comments
-
Farrukh Chishti almost 2 years
I am getting this error for pull:
Your configuration specifies to merge with the ref 'refs/heads/feature/Sprint4/ABC-123-Branch' from the remote, but no such ref was fetched.
This error is not coming for any other branch.
The special thing about this branch is that it is created from the previous commit of another branch.
My config file looks like:[core] repositoryformatversion = 0 filemode = false bare = false logallrefupdates = true symlinks = false ignorecase = true hideDotFiles = dotGitOnly [remote "origin"] url = <url here> fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master [branch "new-develop"] remote = origin merge = refs/heads/new-develop [branch "feature/Sprint4/ABC-123-Branch"] remote = origin merge = refs/heads/feature/Sprint4/ABC-123-Branch
-
fizch over 6 yearsThanks for explaining what the git pull command actually does. I was able to fix my issue by running git fetch and then merge.
-
aerin about 6 yearsIt was the same for me!
-
Yoav almost 6 yearsTo remove non-existent remote branch references in your local repository, use
git remote prune origin
-
torek almost 6 years@Ben-Uri: yes, or, run
git fetch --prune origin
, or setfetch.prune
totrue
in your configuration (all three are intended to do the same thing, although in a few versions of Git some of these were not quite reliable). -
Artokun over 5 yearsAfter a pull request, the merger (i.e. the person who did the merge) has the option to delete the branch that was merged into the target branch. If you try to pull at that point you'll get this error.
-
Pierre over 5 yearsIt's not even necessary to
git push
and it won't work if the current branch is behind its remote.git pull origin correct-branch-name
is enough. -
Malhaar Punjabi about 5 yearsthat is true :)
-
Alexander Shtang almost 5 yearsYou'd need to
git checkout <your remote branch>
and all be good (in some cases). -
Håkon K. Olafsen over 4 yearsThis turned out to be my problem too. It's not necessary obvious with fairly long/complicated branch names.
-
Ankit Marothi over 4 yearsThe command to set upstream is wrong above. Do a git pull after, --unset-upstream operation, in the output of the pull you can see a error, with the command to set the upstream, like below, git branch --set-upstream-to=origin/<branch> mybranch
-
Will Strohl over 4 yearsWow... So weird. This only happens to me when connecting to BitBucket. :(
-
torek over 4 years@WillStrohl: to see what branches the Git at Bitbucket actually has, use
git ls-remote <name-of-bitbucket-remote>
. Your current branch has, as its upstream, a branch name that does not exist in that Git at Bitbucket. How you got there, and what to do about it, is in the answer above. -
Akah over 4 yearsWorked nicely for me after removing some large files from my repo and needed to push back to a new repo i just created
-
Jonathan Benn about 4 yearsThe problem for me was that I deleted a development branch on Github without ever merging it (I abandoned the change). I got the same error message as the original poster. The solution for me was to delete my local
master
branch and re-create it. -
torek about 4 years@JonathanBenn: you can use
git branch --set-upstream-to=origin/master master
to switch the upstream setting for your localmaster
. Delete-and-recreate has that as a side effect (assuming you use the DWIM-stylegit checkout master
to create it), with an additional side effect of forcing yourmaster
to match yourorigin/master
. -
Jonathan Benn about 4 years@torek thanks, my Git-fu was not up to the task on this one. I'll keep in mind your recommendation for next time. I must have created a new local branch based on the deleted remote one, and then renamed my local branch to
master
. -
Ben Thurley about 4 yearsA number of downvotes and yet this was the cause I had of receiving this error. I had Internet but had lost the VPN to my git server. After reconnecting to the VPN the pull worked fine.
-
codeDr almost 4 yearsargh! I ran into this. A github project renamed the master branch main!
-
Ilya Serbis over 3 yearsThis doesn't help with the issue because
core.ignorecase
option only affects your files but not git internal files (which resides in.git
folder) -
Josh Bone over 3 yearsFor anyone visiting this more recently: '--set-upstream' is no longer supported. Now you should use "git branch --set-upstream-to=origin/<branch> main"
-
rob74 over 3 yearsSame here - I guess git tries to fetch something from the remote, silently fails to write it because the disk is full, and then doesn't find the files and complains that the "ref wasn't fetched"?
-
oleksa over 3 years
core.ignorecase true
does not work for me (the problem was a case difference in the branch name). So I've just set upstream to the correct branch name -
Abbas Elmas over 3 yearsthanks for catch! This main master thing is only getting more frustration.
-
gerrit about 3 yearsOr
git fetch upstream
,git checkout main
, then next timegit pull
. -
Vicky Singh over 2 yearsThis was the issue for me as well
-
sbsatter over 2 yearsMerging my staging to main branch - pull request completion deleted my branch. Couldn't find staging later on. Thanks for explaining the options.
-
torek over 2 years@sbsatter: pull requests are outside of Git (Git has no pull requests). GitHub's PR protocol allows you to semi-automatically delete the GitHub branch once the PR is merged. Other hosting sites may have similar features.
-
poitroae over 2 yearsThe only answer that worked
-
Krafty over 2 yearsMy case was very sensitive too!