Windows上的Git text=auto core.autocrlf=false提供CRLFs

这怎么可能？ 我有一个包含以下内容的.gittributes

* text=auto

更新：

---

呵呵。结果是.gittributes文件导致了这种行为。有人能解释一下或指向相关文档吗？

在设置

.gittributes

后，使用

git add--renormalize.

（从包含这些

*.sh

和

*.bash

文件的目录）或

git add--renormalize*.sh*.bash

在提交之前更新文件。或者，使用

touch*.sh*.bash；git checkout-f*.sh*.bash

更新工作树副本

这是怎么回事 毫无疑问，您已经知道，Git存储库包含提交。每个提交都有一个已提交文件的冻结副本，其状态与您（或任何人）提交文件时的状态完全相同。这个冻结副本永远无法更改，因此如果它有CRLF行结尾，它将永远拥有它们，如果它只有LF行结尾，它将永远拥有它们。在将来的任何其他提交中，该文件的任何其他副本都可能不同，但此提交中的此副本已冻结。（任何其他现有提交中的任何副本当然也会被冻结，但可能会有所不同。）

在内部，每个提交的文件都是一种特殊的、仅适用于Git的格式，仅由Git压缩和使用，一旦提交，就会在特定的提交中永久冻结。但当然，您可以通过提取提交的文件来查看这些文件；您还可以创建新的提交文件，使用可以修改的提取文件。因此，Git需要两个操作：

• 将文件从提交复制到您可以处理的位置；及
• 从您处理文件的位置复制文件，以便（准备）提交

这两个操作实际上只对LF执行任何CRLF操作，反之亦然

存放您使用和处理的文件版本的位置，可能毫不奇怪地称为工作树（或者工作树或工作目录的一些变体）。您使用并处理工作树中的文件。您可以告诉Git将文件从提交复制到工作树，或者将文件从工作树复制到（准备）提交

索引 这里还有一个额外的问题，那就是Git根本不会从您的工作树中进行提交。相反，Git在提交和工作树之间插入第三个保留区域。Git将其称为索引、暂存区域，或者有时称为缓存，具体取决于Git的谁/哪个部分在进行调用

索引中的文件始终准备好提交。也就是说，它们具有与提交中相同的特殊、压缩、仅Git格式。这就是使git commit如此快速的诀窍（无论如何，与其他版本控制系统相比）：无论是在任何时候还是几乎所有时间，一切都准备就绪。当您运行

git commit

时，git甚至不会查看工作树。它只是将索引中的文件以现在的形式打包，所有文件都经过压缩、Git化，随时可以使用

git add

命令将文件从工作树复制到索引中，使它们准备就绪。相比之下，

git checkout

命令将文件从提交中复制到索引中，以便为下一次提交做好准备，然后复制到工作树中

这就是为什么需要

git add--renormalize

假设某个文件以某种方式（有或没有CRLF结尾）存储在提交中。运行

git checkout name

来选择分支及其提示提交。提交中的文件进入索引，并从那里进入工作树。“将步骤索引复制到工作”树会将文件更改为有人告诉Git要使用的行尾，可能是通过刚刚签出的提交中的

.gittributes

文件

如果这些都是错误的，您现在可以更改

.gittributes

文件。1这可能会改变文件在下一次提交中的方式。它可能会改变文件在工作树中的方式。但问题是-Git已经以它认为正确的方式在索引和工作树中拥有了文件。

此外，还有一个更糟糕的问题：Git不仅拥有它认为正确的文件，它还认为它不需要对这些文件进行任何新的处理。如果您现在对它们运行

Git checkout

或

Git add

，Git会巧妙地注意到工作树副本没有被触动，并且什么也不做，即使重新签出或重新添加会做一些不同的事情

结果是，实际上，您必须诱使Git重做工作。如果需要根据“从索引到工作树”顺序更新部分或所有工作树文件，则可以针对每个此类文件：

• 删除工作树副本并再次运行

  git checkout

  ，或

• 触摸

  工作树副本（以便Git认为您已经修改了它）并运行

  Git checkout-f

  强制覆盖它们

如果需要根据“从工作树到索引”顺序更新部分或所有工作树文件，可以：

• 触摸工作树副本（以便Git认为您已对其进行了修改）并运行
  Git add
  ，或

• 使用新的ish

  git add--renormalize

  强制git重新添加文件，即使它可以看到您没有碰过它们

如果您的Git太旧，无法使用

Git add--renormalize

，您可以使用

touch

方法

---

---

1这对

core.autocrlf

和

core.eol

都适用，但在这里，最好使用

.gittributes

文件进行更精细的控制。例如，Git维护人员是为Git本身做这件事的。

Git文档对核心的定义是模糊的