Reputation: 8437
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
Upvotes: 594
Views: 640435
Reputation: 71
I faced this issue when accidently set a url of a wrong repo. Try copying the repo URL and set it using the following command.
git remote set-url origin [url of your repo]
Upvotes: 0
Reputation: 141
for me, it was because when I merged develop to master, there was a config to delete the branch after a merge and that was why git pull wasn't working.
so to resolve this scenario, I had to go to the pull request and used the restore branch button to restore the branch.
Upvotes: 1
Reputation: 1079
This was old question, in fact new git users still may experience the same issue
For example:
**you have repoA**
remotes/origin/yourBranch1
**you have repoB**
remotes/origin/yourBranch1
remotes/origin/yourBranch2
You may checkout at yourBranch1 under repoA
and thinking you are deleting remote yourBranch2 under repoB
then you would see below error
'Couldn't find remote ref'
Make sure you did checkout the branch which is under same repo, and is not the same branch that you intended to delete
Upvotes: 0
Reputation: 13108
None of the answers here (including git fetch --prune origin
) worked for me after a rebase
. Here's what did work. Be aware that one of these commands will delete your local branch, so you'd better have it stored on your remote origin
before running:
git checkout master
// Get off the problem branchgit branch -d problemBranch
// Delete the problem branchgit pull
git checkout problemBranch
git push -u
git pull
works without complaintThis resulted in no extra merges nor any problems on any other machines using the repo.
Upvotes: 4
Reputation: 1089
It is also possible that the rights in the GitLab repository were simply missing when cloning the repository.
Upvotes: 0
Reputation: 1263
When i was running 'git pull' command in my root project, following error was coming:
Command:
git pull
Error: Your configuration specifies to merge with the ref 'refs/heads/main' from the remote, but no such ref was fetched.
Soultion:
I simply deleted .git folder and reinitialize .git(created .git folder again) by running git init
command in my root project folder and it worked.
Upvotes: -1
Reputation: 11
I was in the branch that was merged and deleted in the remote. Checking out to a branch that exists and then pulling helped me.
Upvotes: 0
Reputation: 1927
Informal, but deleting my local project and recloning worked.
I was safe doing so as I had never developed a branch for merge.
Upvotes: 0
Reputation: 1048
I just now experienced the problem of "no such ref was fetched", and none of the above suggestions helped. The way I solved it was to change in my local config
remote.origin.fetch=+refs/heads/master:refs/remotes/origin/master
to
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
I have no idea why that worked, but it did. After this change, I could pull and received what I expected.
If I change it back, I again get the "no such ref was fetched" when trying to pull. So this was definitely the fix (not flunky internet, or case differences, or full drive, or deleted remote branch, or default branch not named "master", etc).
Upvotes: 3
Reputation: 3429
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 )
Upvotes: 254
Reputation: 2917
Happened to me when installing packages with yarn
. An own dependency had a renaming of branch main
into master
. Only updating upstream on the dependency did not fix it, I additionally had to clean the yarn
cache.
Project A renamed the main branch (main
-> master
). Project A is a dependency of Project B.
yarn install
on Project B <-- causes error
Push updated upstream on Project A
yarn install
on Project B <-- causes error
yarn cache clean
yarn install
on Project B <-- works now
Upvotes: 0
Reputation: 487725
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.
This depends on what you want. See the discussion section below. You can:
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.
Upvotes: 370
Reputation: 545
I've found this error occurs frequently when pulling updates from a repo whose default master
branch has been renamed to main
.
Encountered this a lot after the 2020 trend of renaming master
branch to main
branch.
So if you had previously cloned a repo with the default master
branch and that branch has since been renamed to main
, one way to fix is by simply pointing your upstream from master to main:
git branch --set-upstream-to=origin/main master
If that command succeeds, you should see a message like this:
Branch 'master' set up to track remote branch 'main' from 'origin'.
You can then rename your local branch from master
to main
(to keep consistent with the remote branch name) with git branch -m master main
Upvotes: 6
Reputation: 1565
I have gotten this exact error, but none of the suggested answers (possibly the case sensitivity) was the issue. They probably are for 99% of the issues out there, but that still leaves 1%.
It turned out, mixing WSL / Linux file shares and Windows base directories was the problem. I was running WSL (Ubuntu 20.04) and has a repo that was accessed / edited from Windows, but the code was running on WSL. I may have done some git status checks from the WSL side.
The repo existed, the case was correct, the internet worked fine, none of the branches were removed, etc. Yet I also got the error Your configuration specifies to merge with the from the remote, but no such ref was fetched.?
What my fix was, was to make sure all of the items were pushed / all changes recorded, then I just removed the directory and did a 'git clone' again from Windows. Then the 'git checkout' worked fine. I realize this isn't really an answer, but it did work.
I was doing Linux development where a code library automates certain operations, including 'git clone'; however, I normally do my code pushes from Windows. My guess is that the .git folder is not cross-platform compatible (not that I had any expectation it was). Yet, it usually works. Is it a bug? Debateable.
git will also occasionally try too hard to be nice and munge line endings; that's a different problem (and bordering on religion. I'm an Agnostic. Yes, there's a setting.)
Upvotes: 0
Reputation: 7199
The branch's pull request in the Github repo was approved, it was merged into the dev branch and doesn't exist on origin any more.
Upvotes: 0
Reputation: 551
In my case, my branch name (remote) had uppercase letters, for example: BranchName
.
Accidently, I created a branch branchname
(all lower case) on my local machine and set upstream to the same, and this error appeared.
Solution:
I deleted the local repository, cloned it again, and checked out to BranchName
Upvotes: 3
Reputation: 475
git branch -m temp
git branch -a
git checkout main
git branch -d temp
Upvotes: 1
Reputation: 339
In my case the master cannot be fetched in a new project.
And it worked after I put this in the command line,
git config --global http.sslVerify false
Upvotes: 0
Reputation: 51
I had a similar issue with master/main branch. In my case I did not have enough free space on my harddisk. After freeing up some space, it worked.
I assume its because the files /.git needs some space to edit its file. For example the file: 'refs/heads/feature/Sprint4/ABC-123-Branch'
Upvotes: 5
Reputation: 169
In my case, I renamed the branch on Github which in return told me to execute the following commands:
The default branch has been renamed!
main is now named <new_name>
If you have a local clone, you can update it by running:
git branch -m main <new_name>
git fetch origin
git branch -u origin/<new_name> <new_name>
git remote set-head origin -a
Upvotes: 2
Reputation: 13451
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
Upvotes: 32
Reputation: 383
You can easily link your local branch with remote one by running:
git checkout <your-local-branch>
git branch --set-upstream-to=origin/<correct-remote-branch> <your-local-branch>
git pull
Upvotes: 11
Reputation: 796
I just got the same error, when I didn't use the correct case.
I could checkout out 'integration'. Git told me to perform a git pull
to update my branch. I did that, but received the mentioned error.
The correct branch name is 'Integration' with a capital 'I'.
When I checked out that branch and pulled, it worked without problem.
Upvotes: 1
Reputation: 1031
In my case, i had deleted the original branch from which my current branch derived from. So in the .git/config file i had:
[branch "simil2.1.12"]
remote = origin
merge = refs/heads/simil2.0.5
rebase = false
the simil2.0.5 was deleted. I replaced it with the same branch name:
[branch "simil2.1.12"]
remote = origin
merge = refs/heads/simil2.1.12
rebase = false
and it worked
Upvotes: 3
Reputation: 757
I was facing the same issue where my current branch was dev and I was checking out to MR branch and doing git pull thereafter. An easy workaround that I took was I created a new folder for MR Branch and did git pull there followed by git clone.
So basically I maintained different folders for pushing code to different branch.
Upvotes: 0
Reputation: 20340
I kept running into this issue. In my case, @Jerreck's comment about case differences in the branch names was the cause of this error. Some Windows tools aren't aware of case sensitivity.
To turn off case-sensitivity in git, run this command:
git config --global core.ignorecase true
Note that this will impact more than branch names. For example, if you have "Foo.h" and "foo.h" in the same directory (not a great idea when building software for Windows) then I suspect you cannot turn off case sensitivity.
Upvotes: 3
Reputation: 978
You can edit the ~/.gitconfig
file in your home folder. This is where all --global settings are saved.
Or, use git config --global --unset-all remote.origin.url
and after run git fetch
with repository url.
Upvotes: 1
Reputation: 21
I just got exactly this error when doing "git pull" when my disk was full. Created some space and it all started working fine again.
Upvotes: 2