向git repo的某个分支提交了两次连续的merge操作，用commitA和commitB表示。

发现在完成commitB时，repo中的某个.hpp文件中的中文注释出现了乱码（中文字符变成问号）；
而在完成commitA但还没提交commitB时，repo中的这个.hpp文件中的中文注释没问题。
也就是说commitB修改了这个hpp文件，但是commitA、commitB的详细信息显示根本都没修改这个.hpp文件。

这个.hpp文件头部的BOM头也一直是UTF-8 with BOM，没变。

那么这个文件是怎么发生变化的呢？

服务端用的是gitlab。客户端没设置过git hooks之类的。

chatgpt的一些提示：

Git钩子（Hooks）：Git钩子是在特定操作（如commit、push）执行前后运行的脚本。如果服务器端（或者客户端）设置了在commit或push时触发的钩子脚本，这些脚本可能会修改文件内容，包括但不限于编码转换操作。这种情况虽然不常见，但是可能会导致文件内容在不触发git变更记录的情况下发生变化。

Git LFS（Large File Storage）：如果你的项目使用了Git Large File Storage (LFS)来管理大文件，那么相关的.hpp文件可能被Git LFS处理过，而Git LFS在某些情况下可能会在不显著改变.git历史的情况下，导致文件内容发生变化。

Git服务端的设置或Bug：虽然Git本身的核心功能相对成熟，bug较少，但并不排除存在会影响文件编码的已知或未知的问题。此外，如果你使用的是像GitHub, GitLab这样的Git托管服务，它们的一些特定设置（例如自动合并策略）或bug可能也会影响文件的状态。查看相关服务的更新日志和已知问题列表可能会有所帮助。
--
FROM 221.220.171.*

别人提交的，应该都是在windows下，自动转CR/LF这个chatgpt倒是也有提示。

dos下fc /b比较二进制，发现前面是一些中文变成了问号0x3F，然后有1个空格的差异导致错位，后面还有些空格和CR、LF的差异。

先让gitlab管理员帮查查服务端的log了。


【 在 ArchLinux 的大作中提到: 】
: 这种情况应该是先比较commitA和commitB里这个文件的差异，在根据文件历史找出问题的提交，实在不行还可以bisect.另外merge commit可以修改有合并冲突的文件的，也可以在merge的过程中做一些其他的修改，这个也要注意。
: 如果是在Windows下操作的话，我记得git的Windows版是有自动转CR/LF这类功能的，不知道你的客户端会不会干类似的事情。
:
--
修改:z16166 FROM 221.220.171.*
FROM 221.220.171.*

这个可以设置的


【 在 xunery 的大作中提到: 】
: 这个应该就是windows提交的时候git自动转换CR/LF导致的，好像没啥好方法，要么给git提交bug，要么在Linux下写代码，要么代码中不用中文
: 在提交代码的时候git会有提示的，也许就是这么设计的
--
FROM 154.17.19.*