我目前正在处理VBScript（* .vbs）文件，该文件只能在Windows上运行。
我希望他们能够忽略开发人员如何设置他们的core.autocrlf而使用CRLF进行结算。顺便说一句，我的false运行时似乎设置为git config --get core.autocrlf
所以我用以下命令创建了一个.gitattributes文件：
*.vbs text eol=crlf
同时提交了文件（及其CRLF EOL）和这个.gitattributes文件。
但是，当我想要查看差异时，例如，我已经对文件做了一些更改，而没有更改EOL。在gitk中，我必须检查忽略空格更改才能正确查看行差异，否则整个文件都被视为已更改。
我做错了什么？
注意：尤其是在SO和其他论坛上，我读到有人说要使用例如*.vbs binary避免Git更改EOL-就像建议对Git在线文档中的*.jpg文件进行更改一样，但是binary的意思是-text -diff，而我不这样做不想（取消）设置-diff，因为我想拥有差异！
答案 0 :(得分：1)
如果您告诉Git不要乱糟糟对待文件，则必须接受这样的事实，即某些文件已永久存储为仅LF的行尾，而另一些文件已永久存储为CRLF的行尾。
如果您告诉Git弄乱文件，不仅会在提取（git checkout）或添加（git add）要以永久格式保存的文件时，而且还会在提取时这样做差异文件。
这是您现在必须选择的内容的 ，因为很明显，您已经拥有带有LF-ony行尾的已提交副本。
声明：
<pattern> text eol=crlf
实际上是对Git的命令，告诉它：
当取出冻结格式的文件 （存储在存储库和索引/暂存区域中时，将其放入工作树中）可以看到并使用它），将所有仅换行符的行尾更改为CRLF行尾。
当您冻结干燥文件时，即，将工作树文件存储到索引中，以使其在下一次提交时进入 并且具有CRLF行尾，请更改它们为仅换行符的行尾。
换句话说，您是在告诉Git：请对我的文件进行处理。 eol=...部分告诉它如何处理文件。该行的 pattern 部分告诉Git 哪些文件，而text指令告诉Git：这些是文本文件，因此它们在我的屏幕上以差异显示OK，您应该将它们弄乱。
如果您将binary用作属性，则会告诉Git：这些是二进制文件，因此它们不会在我的屏幕上显示diff，并且您不应该将它们弄乱完全没有。
与phd noted in a comment一样，您可以使用-text说不要惹他们，而无需也说它们无法显示< / em>。但是说不要与它们混在一起意味着不要与它们混在一起，这包括提取脱水内容物以制成差异时的情况。
全部发生在补液阶段（将冻干的文件恢复为可用文件时）或冻结干燥阶段（将常规文件转换为文件）放入一个可以存储在Git内部的文件中此外，Git内置的文本文件修改过程 all 全部存储在Git内，且仅使用LF行尾。如果这些*.vbs文件 在存储在Git中时必须在其中包含CRLF， 1 则不得在进入过程中对其进行修改，因此您不能使用任何Git的内置修改选项。
如果文件可能（被允许）在Git中存储时仅具有LF行尾，则您可以使用内置的修改。如果它们在工作树中（或您可以查看并使用它们的任何形式）必须具有CRLF行结尾，则和已存储在Git中的现有已提交副本具有仅LF的行结尾，那么您必须选择让Git在进出冻结格式的途中对文件进行更改，因为现在Git内部没有存储任何现有的冻结文件可以更改。 2
如果您可以使用不具有CRLF行结尾的现有冻干副本，则当它们回来时保持这种状态，而新文件将以CRLF行结尾存储在Git中并在进出副本时保留其CRLF行尾，您可以使用-text（或完全不使用 3 ），而不会让Git弄乱他们。
1 我不清楚为什么需要这样做，因为只有Git才能读取Git的冻干存储文件。我这样说是因为这样更容易思考，然后 then 从“绝对必须以这种方式完成”转变为“我希望以这种方式完成”，随着您放松自己约束。
2 当然，您可以选择采用一些现有存储库，然后将其转换到新的不同存储库中，并进行新的不同提交，文件以其他形式。您可以使用git filter-branch ... --all或存储库的某些子集在整个存储库上执行此操作。这样做的好处是您将获得一个“干净”的存储库，就像您很久以前一直在遵循现在建立的任何实践一样。缺点是您必须让拥有原始存储库副本的每个人都切换到使用您今天提出的替换提交。
3 Git的原始概念是，它将永久保存与提交时出现在索引中的文件完全相同的文件。这个概念仍然存在，但是引入了这些修改（将文件从索引中抽出“混入”到工作树中，然后在返回到下一次提交时“清除”它们），使Windows用户可以要求CRLF行尾，与需要仅LF行尾的Linux用户相处。但是它也引入了这种笨拙的情况，在这种情况下，Git现在必须知道应该弄乱了哪些文件，哪些是“文本”，哪些文件不应该，因为它们是“二进制”。消除了数据的混乱，并消除了描述哪些文件受到哪种处理的麻烦。