代码之家 › 专栏 › 技术社区 › Tom Wright

在更改了文件名的大小写之后,git抱怨签出时可能会丢失数据

case-sensitive git

3

Tom Wright · 技术社区 · 7 年前

this answer 我曾经 git mv 更改文件扩展名的大小写。

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

在我看来,git的索引与现实不同步,但我不知道如何修复它。

我的下一步行动是什么?

2 回复 | 直到 7 年前

1

2

torek 7 年前

热释光;DR:您可能只需在签出所需的提交之前删除文件。

readme.txt 当一个名为 README.TXT 存在,这将覆盖现有不创建 自述文件.txt

正如VonC所说,如果与现实格格不入,你可以推翻它。类似地,如果索引中没有任何有价值的内容,则可以删除并重新生成它:

rm .git/index
git reset --mixed HEAD

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

这里的主要问题是Git的内部结构和Git的索引(因为它只是其中的一个数据文件) .git/index ),都使用可以容纳任何文件名,例如包括 自述文件.txt 和 . 任何Linux系统都可以在工作树中存储这两个文件, ¹ 但是典型的MacOS或Windows文件系统不能。在这样的情况下,指数保持不变这两个名称下的文件可以在Linux上同时存在,但不能在您自己的系统上。无论发生什么情况,索引都保证与实际不符。

自述文件.txt 并将该名称存储在索引中,即使操作系统重写了现有的 自述文件.TXT 在工作树上留下了这个名字。

这个 core.ignorecase 设置,当您第一次 git init git clone 自述文件.TXT 在Git尝试创建 自述文件.txt . 在这种情况下,您将看到错误消息,因为Git不确定 自述文件.TXT 自述文件.txt 它之前提取的(也许你删除了那个,然后放了一个不同的你想保留的)。

¹ 这实际上是依赖于文件系统类型的行为,但是默认的Linux文件系统是区分大小写的。在HFS/HFS+On MacOS上,您可以在文件系统构建时选择文件系统是否区分大小写。我相信NTFS也是如此,我从来没有建立过NTFS文件系统。

2

1

VonC 7 年前

然后,如图所示,尝试相同的方法 git mv 在repo的新克隆中,查看那里的索引是否被不可见的未跟踪文件“更少”污染。