122

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 to keep them.

I've tried:

git reset --hard

and I get the same problem

The only thing that seems to work is deleting the offending file and try a git pull again.

I've also tried git stash followed by a git pull. No go.

edit: using PortableGit-1.6.4-preview20090729 so any previous bugs with spurious errors should be fixed.

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
yuit
  • 6,249
  • 5
  • 20
  • 6
  • See if explanation in http://git.or.cz/gitwiki/GitFaq helps. – Jakub Narębski Aug 08 '09 at 12:24
  • Ditto "*The only thing that seems to work is deleting the offending file and try a git pull again.*". For me, at least one file wasn't in git; it was .gitignored by a wildcard rule. Not sure why they were blockers, though. – ruffin Oct 28 '17 at 15:53
  • 6
    I was able to solve this by running `git rm --cached learned/tests/temp_funcs.py` - Since I anyways wanted the file to remain in *Untracked Files* list, `git rm --cached` unblocked me in this case. – Deep Jun 27 '19 at 10:18
  • 3
    This happened to me during a merge that I wished to `--abort`. None of the proposed solutions allowed me to abort, except to delete the offending files. – Trevor Reid Feb 18 '20 at 15:55
  • @TrevorReid thanks for the note. The same problem – Akbar Pulatov Jul 22 '22 at 03:23
  • Had same issue as @TrevorReid. Looked through comments and easiest solution was (I am using IntelliJ IDEA) to just revert/rollback added files. That allowed to abort current merge process. – Eugene Oct 10 '22 at 07:34

15 Answers15

95

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.

habitats
  • 2,203
  • 2
  • 23
  • 31
  • 9
    I was able to solve this by running `git rm --cached learned/tests/temp_funcs.py` - Since I anyways wanted the file to remain in *Untracked Files* list, `git rm --cached` unblocked me in this case. – Deep Jun 27 '19 at 10:17
  • 8
    The `git update-index --really-refresh` was the piece missing! Well done, this was hard to find – Bernardo Dal Corno Oct 23 '19 at 12:28
59

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
manat
  • 1,102
  • 11
  • 13
  • 29
    From the original question: _"I've also tried "git stash" followed by a "git pull". No go."_ – Charles Wood Mar 03 '14 at 14:46
  • 1
    Didn't work for me - in my case I had to `git rm --cached`, full comment: https://stackoverflow.com/questions/1248029/git-pull-error-entry-foo-not-uptodate-cannot-merge#comment100131900_1248029 – Deep Jun 27 '19 at 10:18
  • 2
    For me, the error happens WHEN I try to use `git stash`. – Dan M. Sep 23 '21 at 15:30
29

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.

Brian Campbell
  • 322,767
  • 57
  • 360
  • 340
17

I was seeing a similar issue (Windows 10): I was on branchA and wanted to go to the master branch. I had some uncommitted changes, so first I called git stash, and then git checkout -f master.

Unfortunately, I kept getting the Entry 'fileName' not uptodate. Cannot merge error message.

The command git status didn't show information that there are any changes to commit.

Eventually I just removed the file manually, and was able to go to the other branch (what of course made my file come back). I suspect there was a bug in the Git repository.

Tom Smykowski
  • 25,487
  • 54
  • 159
  • 236
user276648
  • 6,018
  • 6
  • 60
  • 86
  • 1
    This is the only solution to this question that worked for me. I was getting the error with `.gitignore` file! Even though I hadn't made any changes to it, and git wouldn't allow me to "stash" it (because there are no local changes, duh!). So I moved the `.gitignore` file outside the repository (as a sort of "backup") and then did a `git reset --hard`, which "fixed" the repository into a sane state. – Masked Man Jan 30 '18 at 03:53
  • `git status` showed me which file was changed and hinted that I could use `git restore myFile` instead of deleting it, which worked. – Noumenon Mar 16 '20 at 13:51
15

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.

Aggressor
  • 13,323
  • 24
  • 103
  • 182
  • 1
    This answer put me on the right track, thanks. I used "git ls-files -v | grep '^[[:lower:]]' | awk '{print $2}' | xargs git update-index --no-assume-unchanged" to reset the assume-unchanged flag, then I was able to reset --hard without errors. – ocroquette Jun 20 '16 at 07:11
  • I think this also applies to any file marked 'assume-unchanged', I had the same issue for ignoring changes to a local file which had its original name. Your comment reminded me that I had marked that file, thanks! – kira_codes Jul 26 '16 at 15:16
  • 6
    I have the same problem. Basically "assume unchanged" is an evil feature. Once you use it, it makes it VERY difficult to checkout other branches. Even if you use `checkout -f`, it will fail. – John Henckel May 02 '17 at 23:38
14

Generally speaking, this means you have changes in your local files that haven't been committed to your local repository. You can also see this stackoverflow question for a bit more detail.

Community
  • 1
  • 1
codeincarnate
  • 845
  • 7
  • 13
7

It might a problem also with file permissions. Git is versioning them too, unless config says otherwise. Just adding this answer for people who has almost but not the like problem.

Drachenfels
  • 3,037
  • 2
  • 32
  • 47
5

Worth a try:

Could you set, just for this update, set the config parameter core.trustctime to false?

core.trustctime

If false, the ctime differences between the index and the working copy are ignored; useful when the inode change time is regularly modified by something outside Git (file system crawlers and some backup systems).

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 2
    nice find, this actually worked for me when I saw the error message above when running "git reset --merge". When I set this paramater to false, it got rid of the error. – DemitryT May 02 '13 at 19:04
  • 1
    Worked for me when checking for conflicts with another branch using "git merge --no-ff --no-commit" then reverting with "git merge --abort". Xcode was the "something outside of Git" in this case. Thanks nearly 10 years later! – Ralfonso Feb 09 '19 at 03:27
  • @Ralfonso Nearly ten years later, you are most welcome :) – VonC Feb 09 '19 at 08:01
4

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.

Aviad P.
  • 32,036
  • 14
  • 103
  • 124
4

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

Youness Marhrani
  • 1,084
  • 16
  • 8
2

If git update-index --really-refresh doesn't work, try:

git update-index --no-skip-worktree <file>
git reset --hard
Omer
  • 1,050
  • 11
  • 14
0

I had the same error, after a situation where git status said new file: foo.cpp for a file not added to the staging area. i.e. under the "Changes not staged for commit" heading. Very weird, this usually doesn't happen.

Solution: git add foo.cpp, and then git stash worked again.

David Faure
  • 1,836
  • 15
  • 19
0

Came to this question and none of the answers worked for me, so here's what did it: deleting the file.

rm -rf the_conflicting_file

then

git checkout your_branch

Wolfgang
  • 1,328
  • 2
  • 8
  • 11
0

I was also getting the same error but while checking out a different branch. with the error message

error: Entry 'file' not uptodate. Cannot merge.

Turns out the problem is with a file that was previously removed from the index using the below command in the current branch but the same file was committed in the destination branch.

git update-index --skip-worktree foo

So the fix was to update index to include that file

git update-index --no-skip-worktree foo

and the use git stash or git rm to keep or delete the file.

rathourdevesh
  • 1
  • 1
0

Nothing here worked for me, in the end I just put my file in a different file path and then put it back, seems to have did the trick.

code-monkey
  • 236
  • 1
  • 2
  • 11