更改文件名大小写后，git抱怨结帐时可能会丢失数据 [英] After changing the case of a filename, git complains about potential data loss on checkout

问题描述

基于此答案，我使用了 git mv 来更改扩展名的大小写文件名.

Based on this answer I used git mv to change the case of the extension of a filename.

但是，现在，每当我尝试更改分支时，都会出现以下错误:

Now however, whenever I try to change branch, I get the following error:

git checkout MyBranch
error: The following untracked working tree files would be overwritten by checkout:
    MyFile/With/The/OldExtension.Ext
Please move or remove them before you switch branches.
Aborting

我仍然可以使用-force 更改分支，但是出于明显的原因，我真的不想依赖它.

I can still change branches with --force, but don't really want to rely on this for obvious reasons.

在我看来git的索引与现实不同步，但是我不确定如何解决它.

It seems to me that git's index is out of sync with reality, but I'm not sure how to fix it.

我的下一步是什么?

推荐答案

TL; DR:您可以在检出所需的提交之前简单地删除文件.

TL;DR: you can probably simply remove the file before checking out the desired commit.

假设您使用的是使用文件名进行大小写折叠的系统，那么这里的问题是，如果Git尝试在名为 readme.txt 的文件上创建和写入文件，而该文件名为 README.TXT 存在，这将覆盖现有的 README.TXT ，而根本不创建 readme.txt .

Assuming you're on a system that does case-folding with file names, the issue here is that if Git attempts to create and write on a file named readme.txt when a file named README.TXT exists, this will overwrite the existing README.TXT without creating a readme.txt at all.

正如VonC所说，如果索引 与现实不符，您可以覆盖它.同样，如果索引中没有任何值，则可以删除并重建它:

As VonC says, if the index is out of step with reality, you can override it. Similarly, if there is nothing of value in the index, you can remove and rebuild it:

rm .git/index
git reset --mixed HEAD

这使索引与当前提交(而不是当前工作树！)匹配.

This makes the index match the current commit (not the current work-tree!).

这里的主要问题是Git的内部结构和Git的索引(因为它只是 .git/index 中的数据文件)，所有这些都可以使用原始字节串来保存 any文件名，例如同时包含 readme.txt 和 README.TXT .任何Linux系统都可以将两个文件都存储在工作树中， ¹ ，但是典型的MacOS或Windows文件系统则不能.在这种情况下-索引以这两个名称保存两个文件，而这两个文件可以在Linux上同时存在，但不能在您自己的系统上存在-无论如何，索引都保证与现实不同步

The main issue here is that Git's internals, and Git's index (because it's just a data file in .git/index), all work with raw byte-strings that can hold any file name, including for instance a simultaneous readme.txt and README.TXT. Any Linux system can store both files in the work-tree,¹ but a typical MacOS or Windows file system can't. In such a situation—where the index holds both files under those two names that can exist simultaneously on Linux, but not on your own system—the index is guaranteed to be out of step with reality no matter what.

否则，如果索引中只有一个大小写变量，则可能只是您的工作树文件名大小写与索引中存储的大小写不同，该大小写最初与您签出的提交中存储的大小写匹配.如果底层操作系统在切换提交时颠覆了Git尝试创建的文件名，则Git确保已创建(例如) readme.txt 并将其存储在索引中，即使操作系统已覆盖现有的 README.TXT 并将该名称保留在工作树中.

Otherwise—if there's only one case-variant in the index—it may just be that your work-tree file name case differs from that stored in the index, which initially matches that stored in the commit you check out. If/when the underlying OS subverts the file name that Git attempts to create when switching commits, Git is sure that it's created (say) readme.txt and stores that name in the index even though the OS overwrote the existing README.TXT and left that name in the work-tree.

core.ignorecase 设置，当您第一次 git init 存储库时(或 git clone 初始化它时)，Git会自行设置，记录操作系统如何处理文件名，以便Git知道在Git尝试创建 readme.txt 之前检查 README.TXT 是否存在.在这种情况下，您将得到所看到的错误消息，因为Git不确定工作树中的 README.TXT 是否真的是 readme.txt 之前提取的内容(也许您删除了该文件，并在其中保留了另一个 README.TXT 即可保存).

The core.ignorecase setting, which Git sets itself when you first git init the repository (or when git clone initializes it), records how the OS treats file names, so that Git will know to check whether a README.TXT exists before Git attempts to create a readme.txt. In this, er, case, you'll get the error message you're seeing, because Git isn't sure if the README.TXT that's in the work-tree is really the readme.txt that it extracted earlier (maybe you removed that one and put a different README.TXT in that you want to keep).

¹ 这实际上是与文件系统类型有关的行为，但是默认的Linux文件系统区分大小写.在MacOS上的HFS/HFS +上，您可以在文件系统构建时选择文件系统是否区分大小写.我相信NTFS也是这样，而不是我曾经构建过NTFS文件系统.

¹This is actually file-system-type-dependent behavior, but the default Linux file systems are case-sensitive. On HFS/HFS+ on MacOS you can choose, at file system build time, whether the file system is to be case-sensitive. I believe the same is true of NTFS, not that I have ever built an NTFS file system.

这篇关于更改文件名大小写后，git抱怨结帐时可能会丢失数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！