git clone以不可复制的方式修改文件类型和内容

Question

我遇到了git clone的奇怪行为-git clone之后立即修改了托管在bitbucket上的git存储库中的某些文件。 此问题看起来与以下问题中报告的问题类似，

• git clone之后直接显示为已修改的文件
• 即使内容相同，Git状态也会显示文件已更改

但看起来并不完全一样。 就我而言，仅修改了大约两千个文件中的几个。 我在git clone之后立即检测到通过git status的修改。 这些修改后的文件最初是带有ascii编码的文本文件，但是在克隆之后，它们被视为二进制文件，如file命令所示：

norio@machine-original $ file -bi t_pot_2e_fft002.f90
text/plain; charset=us-ascii

norio@machine-new $ file -bi t_pot_2e_fft002.f90
application/octet-stream; charset=binary

其中t_pot_2e_fft002.f90是已发现被修改的文件。

在这些经过修改的文件中，逗号,的一些但不是全部空格 和下划线_替换为一些非ASCII字符，但是我仍然可以通过less命令或emacs读取文件的大部分内容。

我重复克隆了6次到另一个本地目录，然后看到了2次修改。 在其他4次中，没有任何修改。 在修改文件的2种情况下，修改的文件因一种情况而异。

我在machine-original machine-original2 （我再也无法访问它们）上的存储库上进行工作，并推送到bitbucket上的远程存储库并从中获取数据。 现在，我将bitbucket上的此存储库克隆到machine-new 。 git的版本在machine-original版本上为1.9.1 ，在machine-new版本上为2.14.1 。 （编辑： machine-original运行ubuntu 14.04和machine-new运行ubuntu 17.10。）

在我意识到此问题之前，我在machine-original上具有core.filemode=true 。 然后，我将其更改为false，但是我不知道如何将效果传播到远程存储库-我进行了git push ，但仅使Everything up-to-date 。

我没有.gitattributes中提到的文件回答到的上述问题之一。

谁能解释为什么这些不可复制的修饰是在克隆时进行的？ 如果在git clone之后没有通过git status检测到任何修改，继续使用克隆的存储库是否安全？

Answer 1

由于来自不同机器的输出hexdump -bc t_pot_2e_fft002.f90是不同的，这意味着编码是不同的。 也许当文件以一种编码从另一台机器推送时，以及将存储库克隆到另一台机器时，它将以不同的方式编码。

有关编码的更多详细信息，您也可以参考处理不一致或损坏的字符编码 。

当将core.filemode设置为false ，您实际上并没有更改文件，而是“忽略了原始编码”。 对于您的情况，最好将core.filemode设置为false ：

core.fileMode

告诉Git是否尊重工作树中的可执行文件。

当签出标记为可执行文件的文件或签出可执行文件位的不可执行文件时，某些文件系统会丢失可执行文件位。 git-clone 1或git-init 1探测文件系统以查看其是否正确处理了可执行位，并根据需要自动设置了此变量。

但是，存储库可能位于正确处理文件模式的文件系统上，并且在创建该变量时将其设置为true，但以后可以从丢失文件模式的另一个环境中进行访问（例如，通过CIFS挂载导出ext4，访问Cygwin使用Windows或Eclipse的Git创建存储库）。 在这种情况下，可能需要将此变量设置为false。 参见git-update-index 1 。

默认值为true（当未在配置文件中指定core.filemode时）。

更多详细信息，您可以参考core.fileMode 。