Your configuration specifies to merge with the <branch name> from the remote, but no such ref was fetched.?
Asked Answered
Q

37

567

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
Quinlan answered 2/5, 2016 at 14:3 Comment(8)
Can you share the command you're using to do the merge?Miki
This problem can happen when the remote branch has been deleted. Double check if it's really there.Sake
Future readers: If you know the remote branch exists, check if you are ignoring case or not. I had setup a local branch to track a remote branch, but typed the remote's name in all lower case letters. Just had to reconfigure local to track origin/BranchName instead of origin/branchnameTarango
I just had this error and the problem was much simpler than the answers below, I'd lost my VPN connection. So this is also the error you get if git can't access the remote origin server.Ellanellard
With solutions involving pruning the local branches to match the remote, first make sure you are not actually on the deleted branch locally, and especially that you don't have uncommitted changes on that branch.Frostwork
There are excellent answers provided, so no need to add any new answers. But my 2 cents, when i get this message it means that the origin branch has been deleted, usually because it was deleted when it was merged into another branch. This is a common practice to keep the origin repo free of clutter from old branches.Akbar
This just happened to me, Github deleted my branch on merge (this merge was done using the website, while I usually use the gh command-line program), it is as @BennyNeugebauer points out, make sure the branch is not deleted on remote.Homicide
As @Akbar mentioned this is likely to be because the branch was deleted (to keep things tidy) when it was merged into master. For example gitlab encourages this with a checkbox on the merge page. You can see whether the branch was merged at #227476. So using git branch --merged master. If it has indeed been merged you are fine; clear the 'error' message with git branch --set-upstream-to=origin/masterRanaerancagua
T
359

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.

Tmesis answered 2/5, 2016 at 18:41 Comment(12)
Thanks for explaining what the git pull command actually does. I was able to fix my issue by running git fetch and then merge.Quit
To remove non-existent remote branch references in your local repository, use git remote prune originSolano
@Ben-Uri: yes, or, run git fetch --prune origin, or set fetch.prune to true 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).Tmesis
You'd need to git checkout <your remote branch> and all be good (in some cases).Coin
Wow... So weird. This only happens to me when connecting to BitBucket. :(Crispation
@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.Tmesis
The 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.Zumwalt
@JonathanBenn: you can use git branch --set-upstream-to=origin/master master to switch the upstream setting for your local master. Delete-and-recreate has that as a side effect (assuming you use the DWIM-style git checkout master to create it), with an additional side effect of forcing your master to match your origin/master.Tmesis
@Tmesis 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.Zumwalt
argh! I ran into this. A github project renamed the master branch main!Proliferation
Merging my staging to main branch - pull request completion deleted my branch. Couldn't find staging later on. Thanks for explaining the options.Dealer
@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.Tmesis
M
231

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 )

Mortonmortuary answered 4/1, 2018 at 16:57 Comment(9)
It'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.Anatola
The 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> mybranchZaffer
Worked nicely for me after removing some large files from my repo and needed to push back to a new repo i just createdMotif
For anyone visiting this more recently: '--set-upstream' is no longer supported. Now you should use "git branch --set-upstream-to=origin/<branch> main"Squarrose
The only answer that workedEdmea
happened for me, that intelliJ was showing wrong branch I was on... thought I was on develop. After "git checkout develop", "git pull" passed without problems.Tannin
I had changed local branch from master to main, and when git pull, this error happened, exactly as you described your way worked nicely for me!Giannagianni
This should be the accepted answer.Branca
I second this. It was my issue with branch name being in uppercase, e.g. TASK-83, while i checked out with task-83. Surprisingly, it worked, but caused this error. Oh, git, you always surprise me ;)Polypetalous
W
60

Check if your remote branch is available to pull. I had the same issue, finally realized the remote branch was deleted by someone.

Weapon answered 19/10, 2017 at 22:20 Comment(4)
It was the same for me!Kevenkeverian
After 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.Homoio
that is true :)Weapon
Same for me. I accidently deleted the branch...Kedge
P
32

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
Photocopier answered 20/7, 2020 at 18:27 Comment(2)
thanks for catch! This main master thing is only getting more frustration.Scheelite
Or git fetch upstream, git checkout main, then next time git pull.Flodden
W
16

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.

Whiff answered 16/10, 2017 at 18:33 Comment(3)
This turned out to be my problem too. It's not necessary obvious with fairly long/complicated branch names.Eohippus
This was the issue for me as wellShumaker
My case was very sensitive too!Moyer
P
11

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
Prototype answered 3/1, 2020 at 11:33 Comment(0)
A
8

I got a similar error when the actual cause was that my disk was full. After deleting some files, git pull began to work as I expected.

Audiphone answered 12/2, 2017 at 16:39 Comment(1)
Same 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"?Communicate
S
7

In my case I was simply lacking of initial commit on remote branch, so local branch wasn't finding anything to pull and it was giving that error message.

I did:

git commit -m 'first commit' // on remote branch
git pull // on local branch
Stucco answered 21/4, 2017 at 8:28 Comment(0)
H
6

This error can also be received when the origin branch name has some case issue.

For example: origin branch is team1-Team and the local branch has been checkout as team1-team. Then, this T in -Team and t in -team can cause such error. This happened in my case. So, by changing the local name with the origin branch's name, the error was solved.

Hagi answered 28/11, 2017 at 9:8 Comment(0)
E
6

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

Easy answered 8/1, 2022 at 16:40 Comment(0)
I
5

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'

Illicit answered 6/4, 2021 at 8:31 Comment(0)
U
3

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.

Uphemia answered 18/3, 2019 at 18:5 Comment(2)
This doesn't help with the issue because core.ignorecase option only affects your files but not git internal files (which resides in .git folder)Shan
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 nameTipper
V
3

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

Venable answered 30/6, 2019 at 11:34 Comment(0)
F
3

Check for case sensitivity

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

Frodeen answered 17/6, 2021 at 15:50 Comment(1)
This was the case for me as well. I was working on windows (case insensitive) and my remote was a case-sensitive system. Further the remote was deleted and a new branch created with the same name, but a different capitalization. My solution was to edit .git/config in my project root, find the relevant branch entry and correct the capitalization in the merge = linePasqualepasqueflower
G
3

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

Gensmer answered 11/11, 2022 at 18:44 Comment(1)
answer to why git removed "master" bbc.com/news/technology-53050955Parallelogram
T
3

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 branch
  • git branch -d problemBranch // Delete the problem branch
  • git pull
  • git checkout problemBranch
  • git push -u
  • Now git pull works without complaint

This resulted in no extra merges nor any problems on any other machines using the repo.

Toowoomba answered 11/4, 2023 at 23:48 Comment(0)
T
2

For me this happened because i merged a branch dev into master using web interface and then tried to sync/pull using VSCode which was open on dev branch.(its weird that i could not change to master without getting this error.)

git pull
Your configuration specifies to merge with the ref 'refs/heads/dev'
from the remote, but no such ref was fetched.'

It makes sense that is not finding it refs/heads/dev - for me it was easier to just delete the local folder and clone again.

Translucid answered 23/9, 2017 at 5:47 Comment(3)
I understand this perfectly. The development branch existed (was first created in the origin) but at some point in time that branch got merged to master and deleted. Which is ok. But I can't stand there is no easy way to simply sync that from the origin. If the branch was merged and deleted in the origin, I don't need it locally either. Why can't git pull or git fetch simply get rid of the dangling obsolete local branch automatically?Academician
@Simón because your local dev branch might contain changes you want to keep but not synced yet. Imagine Johnny boy over there merges his changes from his dev branch into master and per your suggestion git syncs and deletes your local dev branch...with due tomorrow, critical changes :)Translucid
Not necessarily. Git can easily tell if your local branch is ahead of the remote's. Maybe this is just a nuance that comes with adhering to GitHub's recommended workflow, for example: a branch is created on GitHub for each bug/FR/issue, a dev checkouts that branch in their local workspace (GitHub tells you how), works on code, commits, pushes, and generates a pull request; then the repo owner merges the pull request and deletes the branch. Then the dev does git pull and sees this message, and they have to manually delete the obsolete branch, a step that git could have performed automatically.Academician
S
2

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.

Scholasticate answered 10/1, 2019 at 12:19 Comment(0)
G
2

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
Gogh answered 3/4, 2021 at 11:20 Comment(0)
S
1

Just check if someone deleted the branch at remote.

Shamrao answered 1/11, 2018 at 5:30 Comment(0)
O
1

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.

Owlish answered 7/11, 2019 at 9:54 Comment(0)
P
1
  1. Rename the local branch
git branch -m temp
  1. Display all branches
git branch -a
  1. Check out the specific remote branch
git checkout main
  1. Delete the temp branch
git branch -d temp
Pinfish answered 31/8, 2021 at 3:18 Comment(0)
F
1

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.

Fortalice answered 23/11, 2023 at 8:31 Comment(0)
P
0

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.

Palaeography answered 30/1, 2019 at 11:38 Comment(0)
T
0

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.

Tybalt answered 29/3, 2019 at 14:9 Comment(0)
H
0

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

ref: https://confluence.atlassian.com/bitbucketserverkb/can-t-access-bitbucket-server-with-git-issuer-certificate-is-invalid-779171808.html

Hippocrates answered 17/6, 2021 at 18:25 Comment(0)
C
0

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.

Citron answered 13/12, 2021 at 14:47 Comment(0)
H
0

In my case the repo was temporary unavailable (under maintenance).

Henghold answered 14/12, 2021 at 14:51 Comment(0)
D
0

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

Dionysian answered 28/12, 2021 at 17:10 Comment(0)
C
0

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.

  1. Project A renamed the main branch (main -> master). Project A is a dependency of Project B.

  2. yarn install on Project B <-- causes error

  3. Push updated upstream on Project A

  4. yarn install on Project B <-- causes error

  5. yarn cache clean

  6. yarn install on Project B <-- works now

Cindacindee answered 4/3, 2022 at 8:47 Comment(0)
W
0

Informal, but deleting my local project and recloning worked.

I was safe doing so as I had never developed a branch for merge.

Wallop answered 5/12, 2022 at 13:6 Comment(0)
S
0

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.

Stepaniestepbrother answered 6/12, 2022 at 17:6 Comment(0)
C
0

It is also possible that the rights in the GitLab repository were simply missing when cloning the repository.

Conscious answered 6/1, 2023 at 14:54 Comment(0)
A
0

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

Aiden answered 25/7, 2023 at 15:16 Comment(0)
B
0

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]
Brotherinlaw answered 20/3 at 12:49 Comment(0)
P
-1

If another pull just works, it means your internet wasn't connected.

Prichard answered 4/8, 2017 at 16:49 Comment(1)
A 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.Ellanellard
S
-1

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.

Sadi answered 8/12, 2022 at 11:31 Comment(1)
This loses all local repo contents: unpushed branches, stash contents, tags etc.Pink

© 2022 - 2024 — McMap. All rights reserved.