git的core.precomposeunicode=true全局设置安全吗？

Question

我们正在建立一个混合环境(OSX、Linux、Windows)下的git 1.8，而且有一些文件名包含非英文字符。我读到说在OSX系统上需要将core.precomposeunicode设置为true。

我们不关心向后兼容性，但是我们很关心让开发人员保持简单。我们宁愿不解释git配置。

所以问题来了：在全局(中央git服务器)设置该标志是否安全？这将强制执行我们需要的一致性吗？有没有什么原因不这样做？

- egrunin

Answer 1

不，那样行不通。在一个分布式版本控制系统中，不存在所谓的集中git服务器-至少从技术上讲没有。

每个开发人员都有自己的存储库，他会将修改检入该库。当这些更改被推送到您声明为中央的存储库时，数据不会被重新处理。

你必须在每个本地存储库上设置该配置。
不幸的是，《.gitattributes》也没有替代方案。

对于随后由开发人员克隆的某个存储库的本地选项也不是一个选择。以下简单的实验说明了这一点:

d:\Temp\Origin>git init
Initialized empty Git repository in d:/Temp/Origin/.git/

d:\Temp\Origin>git config --local --add core.autocrlf input
d:\Temp\Origin>git config --local --list
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
core.autocrlf=input
d:\Temp\Origin>cd ..
d:\Temp>git clone d:\Temp\Origin Developer
Cloning into 'Developer'...
warning: You appear to have cloned an empty repository.
done.

d:\Temp>cd Developer

d:\Temp\Developer>git config --local --list
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
remote.origin.url=d:\Temp\Origin
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master

请注意，在Origin中调用git config --local --list，会列出core.autocrlf=input，但在Developer中执行相同的命令却没有，尽管我们刚刚是从Origin克隆的。
这说明存储库本地配置值并未被克隆。

- Daniel Hilgarth

---

我听到的是我们想要“在服务器上设置变量，以便用户继承”-你是说这不是它的工作方式吗？（我在git文档中找不到清晰的解释，但可能我不知道该问什么。） - egrunin

@egrunin：就像我说的那样：从技术上讲，根本就没有中央服务器。所有存储库在技术层面上都是相同的级别。您只能针对特定存储库设置配置选项。但是克隆它时将不会“传输”该选项。 - Daniel Hilgarth

+1 这非常有帮助。我将向团队展示这个，并确保我已经正确地代表了我们的问题。 - egrunin

我们这边还在争论，但是我还是给你点赞 - 感谢你的深入回答！ - egrunin

@egrunin：不客气 :) 与git一起工作有时需要所有人都有点纪律。不过有一个想法：您可以创建一个脚本，用于创建初始克隆并设置正确的本地配置。 - Daniel Hilgarth

Answer 2

虽然存储库本地配置值不会被克隆，但 Git 2.37（2022 年第三季度）在 Mac 上更加健壮，特别是对于 core.precomposeunicode，用于 fsmonitor（一个使用特定于平台的文件系统通知工具监视工作目录中的文件和目录更改的守护程序，直接与像 git status 这样的命令进行通信）。

这样，设置 core.precomposeunicode 为 true 就可以得到更好的管理。

查看 提交 3294ca6, 提交 53fcfbc, 提交 eb29901, 提交 00991e1, 提交 9915e08, 提交 d6d58ff, 提交 caa9c37, 提交 f954c7b, 提交 7667f9d, 提交 b533708, 提交 95a4e78, 提交 de7e0b5, 提交 6504cfd, 提交 90a70fa, 提交 d060555, 提交 207534e, 提交 802aa31, 提交 39664e9, 提交 8e8f4b8, 提交 9968ed7, 提交 ddc5dac, 提交 d989b26, 提交 1e7be10, 提交 a85ad67, 提交 5c58fbd, 提交 d33c804, 提交 62a62a2, 提交 49b398a, 提交 27b5d41, 提交 40f865d (2022年5月26日) 由 Jeff Hostetler (Jeff-Hostetler) 提交。
查看 提交 852e2c8 (2022年3月25日) 由 Junio C Hamano (gitster) 提交。
^{(在 提交 9e496ff 中，由 Junio C Hamano -- gitster -- 合并，2022年6月10日)}

fsmonitor: 在 macOS 上还会发出 NFD 路径名的 NFC 拼写

^{Signed-off-by: Jeff Hostetler}

发出 macOS 上路径名的 NFC 或 NFC 和 NFD 拼写。 MacOS 是 Unicode 组合不敏感的，因此 NFC 和 NFD 拼写被视为别名并且冲突。 虽然文件系统事件中路径名的拼写取决于底层文件系统，例如 APFS、HFS+ 或 FAT32，但无论文件系统如何，操作系统都会强制执行这种冲突。 教导守护进程始终报告 NFC 拼写，并在磁盘上以该格式存储时报告 NFD 拼写。 这比 "core.precomposeUnicode" 稍微更通用。

- VonC