Git pull from remote but no such ref was fetched

git

I have a git mirror on my disk and when I want to update my repo with git pull it gives me error message:

 Your configuration specifies to merge with the ref '3.5/master' from the remote, but no such ref was fetched.

It also gives me:

  1ce6dac..a5ab7de  3.4/bfq    -> origin/3.4/bfq
  fa52ab1..f5d387e  3.4/master -> origin/3.4/master
  398cc33..1c3000a  3.4/upstream-updates -> origin/3.4/upstream-updates
  d01630e..6b612f7  3.7/master -> origin/3.7/master
  491e78a..f49f47f  3.7/misc   -> origin/3.7/misc
  5b7be63..356d8c6  3.7/upstream-updates -> origin/3.7/upstream-updates
  636753a..027c1f3  3.8/master -> origin/3.8/master
  b8e524c..cfcf7b5  3.8/misc   -> origin/3.8/misc
  * [neuer Zweig]     3.8/upstream-updates -> origin/3.8/upstream-updates

When I run make menuconfig it gives me Linux version 3.5.7? What does this mean? How can I update my repo?

Best Answer

Check the branch you are on (git branch), check the configuration for that branch (in .../.git/config), you probably are on the wrong branch or your configuration for it tells to merge with a (now?) non-existent remote branch.

Related Solutions

Does git pull after init remove untracked files

A git pull will not overwrite local changes unless you use git add before. Even in this case, you can still recover your data.

When you issued git add before the pull:

mkgithub blub
cp test.sh blub/
cd blub/
git add test.sh
git pull

The pull will delete test.sh. It will only do this if you have no commit in the local repo. After adding a commit this won't remove test.sh (git either ignores it or reports a merge conflict)

The file is not lost. It's still in the Git repository as a dangling blob.

To recover the file:

$ git fsck
Checking object directories: 100% (256/256), done.
Checking objects: 100% (401/401), done.
dangling blob 541060d8292ff808c9715265d063f1bae220da7c
$ git show 541060d8292ff808c9715265d063f1bae220da7 > test.sh

This works as long as you did not issue git gc --prune=now afterwards.

How did `git pull` eat the homework

Yes, git ate my homework. All of it.

I made a dd image of this disk after the incident and messed around with it later. Reconstructing the series of events from system logs, I deduce what happened was something like this:

A system update command (pacman -Syu) had been issued days before this incident.
An extended network outage meant that it was left re-trying to download packages. Frustrated at the lack of internet, I'd put the system to sleep and gone to bed.
Days later the system was woken up and it started finding and downloading packages again.
Package download finished sometime just before I happened to be messing around with this repository.
The system glibc installation got updated after the git checkout and before the git pull.
The git binary got replaced after the git pull started and before it finished.
And on the seventh day, git rested from all its labors. And deleted the world so everybody else had to rest too.

I don't know exactly what race condition occurred that made this happen, but swapping out binaries in the middle of an operation is certainly not nice nor a testable / repeatable condition. Usually a copy of a running binary is stored in memory, but git is weird and something about the way it re-spawns versions of itself I'm sure led to this mess. Obviously it should have died rather than destroying everything, but that's what happened.

Best Answer

Related Solutions

Does git pull after init remove untracked files

How did `git pull` eat the homework

Related Question