Git pull: error: Entry foo not uptodate. Cannot merge

Question

I\'m trying to update my repo from a remote branch and keep getting this error when I do a \"git pull\". I haven\'t made any local changes, and even if I have I don\'t need

Answer 1

There's a couple of ways to fix this but I've found git stash works good for me. It temporary puts your local changes into another place. Then you can pull, to grab the latest changes. And then you can get your local changes back.

Just like this:

$ git pull
...
...
file your_file.rb not up to date, cannot merge.

$ git stash
$ git pull
$ git stash pop

Answer 2

This may happen if you update the index to ignore certain files:

git update-index --assume-unchanged <file>

and then for instance checkout some other branch:

git checkout <branch>
> error: Entry '<file>' not uptodate. Cannot merge.

Forcing index refresh fixes the issue:

git update-index --really-refresh
<file>: needs update

Followed by:

git reset --hard 

And then everything should be back to normal.

Answer 3

This sort of problem is frequently caused by trying to pull from a repository that has two filenames that differ only in case. If you are on FAT, NTFS in case-insensitive mode (essentially, any time it's being used under Windows), or HFS+ in case-insensitive mode, and have two files "foobar" and "FOOBAR", then Git will see two distinct files, but the filesystem will only see one, which will cause all kinds of problems. Git will checkout, say, "FOOBAR", and then checkout "foobar", which the filesystem sees as simply replacing the contents of "FOOBAR" but leaving it in place. Now to Git, it appears that "FOOBAR" has been replaced with the contents of "foobar", and "foobar" is gone.

There are two different manifestations of this basic problem. One is when your repository actually contains two files that differ only on case. In this case, you need to work on a case-sensitive file system, or you will need to edit the repository to ensure that no collisions of this sort occur; a case-insensitive file system simply cannot store the contents of this repository.

A different case that you can workaround is when a rename happens that changes the case of the file. Say, for example, that the Git repository contains a rename from "EXAMPLE" to "example". Before Git checks out the new version, it will try and check to make sure it's not overwriting some existing file that you have on your disk. Since it thinks that "example" is a new filename, it will ask the filesystem if it exists, and the filesystem will see "EXAMPLE" and say yes, so Git will refuse to check out the new version since it thinks it will be overwriting untracked files. In this case, if you have no local changes that you care about, a simple git reset --hard <revision-to-checkout> will generally be sufficient to get you past the problem and to the new revision. Just try and remember not to rename files to other names that differ only in case if you're on a case-insensitive file system, as it will cause problems like this.

Answer 4

For further elaborate on @Brian Campbell's post (because reset hard didn't work either) I want to point out an edge case that was stopping me.

I had moved a file OldFile to a different folder and renamed it NewFile. I then flagged the the file as assume-unchanged.

This was preventing me from switching branches and there was no stash to save or commit to push. The problem was I didn't commit this file change with a new name before setting the assume-unchanged flag. So I set it back to no-assume-unchanged, committed it, then set it back to assume-unchanged and I could switch branches again.

Answer 5

I was trying to perform git merge --abort. The command git restore your_file has fixed the issue for me

Answer 6

Adding my answer because none of the others mention this. In my case this happened after I added new files into the index with the -N flag, so just adding them to the index without adding their content. In this state, doing git stash yields this error.