Git pull：错误：条目 foo 未更新。无法合并

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

提问by yuit

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.

我正在尝试从远程分支更新我的存储库，并在执行“git pull”操作时不断收到此错误。我没有进行任何本地更改，即使我有我也不需要保留它们。

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.

唯一似乎有效的是删除有问题的文件并再次尝试 git pull。

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

我也试过git stash后跟一个git pull. 不行。

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

编辑：使用 PortableGit-1.6.4-preview20090729，因此应修复任何先前带有虚假错误的错误。

回答by manat

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.

有几种方法可以解决这个问题，但我发现 git stash 对我很有用。它暂时将您的本地更改放到另一个地方。然后你就可以拉，来抓取最新的变化。然后您可以恢复本地更改。

Just like this:

像这样：

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

$ git stash
$ git pull
$ git stash pop

回答by Brian Campbell

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.

此类问题通常是由于尝试从具有两个仅大小写不同的文件名的存储库中提取而引起的。如果您使用 FAT、NTFS 不区分大小写模式（基本上，任何时候在 Windows 下使用它），或使用 HFS+ 不区分大小写模式，并且有两个文件“foobar”和“FOOBAR”，那么 Git 将看到两个不同的文件，但文件系统只会看到一个，这会导致各种问题。Git 将签出，比如说，“FOOBAR”，然后签出“foobar”，文件系统认为它只是替换了“FOOBAR”的内容，但将其保留在原地。现在对于 Git，似乎“FOOBAR”已被替换为“foobar”的内容，而“foobar”不见了。

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.

您可以解决的另一种情况是重命名会更改文件的大小写。例如，假设 Git 存储库包含从“EXAMPLE”到“example”的重命名。在 Git 检出新版本之前，它会尝试检查以确保它没有覆盖您磁盘上的某些现有文件。由于它认为“example”是一个新的文件名，它会询问文件系统是否存在，文件系统会看到“EXAMPLE”并说是，所以Git会拒绝检查新版本，因为它认为它会被覆盖未跟踪的文件。在这种情况下，如果您没有关心的本地更改，一个简单的git reset --hard <revision-to-checkout>通常足以让您解决问题并进行新的修订。只要尝试记住不要将文件重命名为其他不同的名称，除非您在不区分大小写的文件系统上，因为它会导致这样的问题。

回答by habitats

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.

然后一切都应该恢复正常。

回答by codeincarnate

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 questionfor a bit more detail.

一般来说，这意味着您的本地文件中有未提交到本地存储库的更改。您还可以查看此stackoverflow 问题以了解更多详细信息。

回答by Aggressor

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.

为了进一步详细说明@Brian Campbell 的帖子（因为 reset hard 也不起作用），我想指出一个阻止我的边缘情况。

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

我已将一个文件移动OldFile到不同的文件夹并将其重命名为NewFile. 然后我将该文件标记为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-unchangedflag. So I set it back to no-assume-unchanged, committed it, then set it back to assume-unchangedand I could switch branches again.

这阻止了我切换分支，并且没有要保存或提交推送的存储。问题是我没有在设置assume-unchanged标志之前使用新名称提交此文件更改。所以我将它设置回no-assume-unchanged，提交它，然后将它设置回assume-unchanged，我可以再次切换分支。

回答by user276648

I was seeing a similar issue (Windows 10): I was on branchAand wanted to go to master. I had some uncommited changes so first I git stashthen git checkout -f masterbut I still got the Entry 'fileName' not uptodate. Cannot merge.

我看到了一个类似的问题（Windows 10）：我在上branchA，想要去master. 我有一些未提交的更改，所以首先我git stash然后git checkout -f master但我仍然得到了Entry 'fileName' not uptodate. Cannot merge.

git statuswasn't showing anything to commit.

git status没有显示任何提交。

Eventually I just removed the file manuallyand I was able to go to the other branch (which of course made my file come back) so I guess there has been a bug within git somewhere.

最终，我只是手动删除了该文件，并且能够转到另一个分支（这当然使我的文件回来了），所以我猜 git 中的某个地方存在错误。

回答by Drachenfels

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.

文件权限也可能有问题。Git 也在对它们进行版本控制，除非 config 另有说明。只是为几乎但没有类似问题的人添加这个答案。

回答by VonC

Worth a try:

值得一试：

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

您能否仅针对此更新将config 参数core.trustctime设置为 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).

如果为 false，则忽略索引和工作副本之间的 ctime 差异；当 inode 更改时间被 Git 之外的东西（文件系统爬虫和一些备份系统）定期修改时很有用。

回答by Aviad P.

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 -Nflag, so just adding them to the index without adding their content. In this state, doing git stashyields this error.

添加我的答案，因为其他人都没有提到这一点。在我的情况下，这是在我将新文件添加到带有-N标志的索引之后发生的，所以只需将它们添加到索引而不添加它们的内容。在这种状态下，执行会git stash产生此错误。