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.
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.
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.
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).
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.
I was trying to perform git merge --abort. The command git restore your_file has fixed the issue for me
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.
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
If git update-index --really-refresh doesn't work, try:
git update-index --no-skip-worktree <file>
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.
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.