文件名中的变音字符导致subversion和git（MacOS）之间的差异

我有带变音字符的文件名（即Exposé.pdf）

我使用的是subversion和git（不是git svn）。 我正在从subversion迁移到git，希望能共存一段时间。 因此，我在多台设备上拥有大型存储库。当我用git克隆一个repo，并将已经存在的subversion.svn文件夹添加到repo时，我得到了subversion差异（！Item is missing，？Item不在vcs下），但文件名似乎完全相同，但在引擎盖下它们不是！ 我试过了（见）

但这没有任何区别。有什么线索吗？

问题可能出在“多个设备”上。确切的修复或解决方法可能是什么还不清楚。见下面的技术细节

一般来说，你不应该自己设置

core.precomposeunicode

，就像你不应该自己设置

core.ignorecase

一样。1这些设置以及

core.symlnks

，都是Git自己设置的，用来记录你的计算机的行为，在运行

git init

或

git clone

.2时，如果您已使用

--global

进行设置，我建议您从个人git配置中删除该设置：

git config --global --unset core.precomposeunicode

全局取消设置此项的原因是，使用

--global

设置值会禁用新存储库中的自动检测功能

启用自动传感后，始终可以将现有存储库克隆到新副本。新克隆将具有适用于即时本地条件的正确（本地）设置。此新克隆不应通过

git clone

以外的任何方式从一台机器传输到另一台机器

---

1这些可以用任意大小写拼写。Git文档使用，将它们称为

core.precomposeUnicode

和

core.ignoreCase

。您可以将它们设置为特定的测试目的，或者设置为处理以某种不希望的方式构建的存储库的奇怪边缘情况。但这相当于对Git撒谎，所以要小心！在进行试验时，在本地（而不是在全球）进行试验

2这里还有一个特例。拥有这些的操作系统。。。以屏蔽丑陋现实的名义对文件名造成伤害的“特性”通常是基于每个文件系统进行的。例如，MacOS的机箱折叠功能在构建磁盘映像时是可变的。Windows上的符号链接支持取决于Windows版本和几个附加项。因此，可以原封不动地拾取Git存储库，将其移动到不同的文件系统，然后需要更改设置。这就是为什么从一个文件系统到另一个文件系统进行

git克隆

通常比使用

tar

或

rar

或

zip

甚至

cp-r

移动git存储库更明智的原因之一：克隆将正确设置，而非克隆复制操作则不会

---

文件名是字节字符串，除非不是 这里最基本的问题是Git希望相信文件名只不过是有两到三个约束的字节字符串，3个由Linux建立，没有其他任何操作系统建立的约束。这些字节字符串通常也应该是有效的UTF-8序列，但不是必须的。理想情况下，操作系统将允许Git不受干扰地按原样使用这些字节字符串

在Windows和MacOS上，这一理想立即难以实现。最明显和最直接的问题是，在Linux上，您可以创建一个名为

README

的文件，然后创建另一个名为

README

的不同文件，这两个文件将共存。在Windows和MacOS上，当您创建其中任何一个文件时，就不能再创建第二个文件：任何这样做的尝试都会重复使用第一个文件

换句话说，Linux有区分大小写的文件名，而Windows和MacOS没有。这意味着Linux用户可以自由创建

README.txt

和

README.txt

文件，并将它们放在一个存储库中。克隆此存储库的Windows或MacOS用户无法同时处理这两个文件

尽管如此，Windows或MacOS上的Git用户可以使用这些文件。这样做很痛苦。我在回答问题时展示了一种方法。同样的方法也适用于这里，同样的痛苦

同样的规则也适用于某些Unicode文件名。特别是，Unicode有多种方法来拼写某些重音字符，如á、ü等。例如，如果我们有一个名为schön（pretty）的文件，我们可以使用字母序列来拼写：

s c h umlaut-o n

（每个都是一个Unicode代码点），或者我们可以使用以下方式拼写：

s c h o combining-umlaut n

这些是不同的字节码序列，因此根据Git至少应该是不同的文件，即使它们在屏幕上显示为名称

schön

MacOS说这两个名字显示相同，因此我不允许其中一个。如果您向操作系统提供了“错误”的拼写，它将要么纠正它，要么干脆拒绝它。请注意，这与大小写折叠情况有所不同：MacOS将允许您创建

自述文件

或

自述文件

，但不能同时创建两者。它只允许一种形式的

schön

由于Git从索引而不是从文件系统构建新提交，并且索引是一个普通的数据文件，因此您可以将所需的拼写或甚至两者都放入索引中。这意味着您可以将其中一个或两个放入新提交中任何现有提交都具有现有拼写，无法更改。

加载现有提交（通过git checkout）将提交的拼写复制到索引中，并保持原样。

core.precomposeunicodes c h umlaut-o n

s c h o combining-umlaut n