git行尾符: renormalize似乎没有检出正确的行尾符

Question

git行尾符: renormalize似乎没有检出正确的行尾符

7

我决定通过一个.gitattributes文件以正确的方式设置我的行结尾，详见例如此处 - 所以我将core.autocrlf设置为false，并创建并提交了一个.gitattributes文件：

*.java text eol=native
*.jsp text eol=native
*.css text eol=native
*.html text eol=native
*.js text eol=native
*.xml text eol=native
*.sql text eol=native
*.MF text eol=native

# git files
*.gitignore text eol=native
*.gitattributes text eol=native

#eclipse files
*.classpath text eol=native
*.project text eol=native
*.prefs text eol=native
*.properties text eol=native

我接着执行了git rm --cached -r .，然后执行了git reset --hard（也尝试了git checkout HEAD），如这里所建议的。现在所有文件都有LF换行符。难道不应该是CRLF吗？我错过了什么？我使用的是Windows 7，git version 1.8.0.msysgit.0。谢谢。

- Mr_and_Mrs_D

@VonC：我执行了 rm .git/index 然后 git reset，但是没有任何变化 - 我已经提交了 gitattributes - 不管怎样奇怪的是 checkout 应该检出 Windows 行结尾 - 我错过了什么吗？我编写的 gitattributes 似乎没问题，对吧？ - Mr_and_Mrs_D

@VonC：我回滚了并按照步骤进行，但是没有用 - 仍然坚持使用Unix行结束符检出。 - Mr_and_Mrs_D

@VonC：显然是一个错误 - 请参见我下面的答案（并根据您的需要进行编辑 - 没有时间正确报告错误）。 - Mr_and_Mrs_D

4

@patthoyts：我刚看到你与Git有关系，所以我会回答你的评论。通常我不会这样做，因为我不喜欢受到居高临下的态度。我没有说我不会报告问题，我只是说我没有这样做。然而，在Git的邮件列表中我回答了一个两年前的帖子，其中清楚地报告了这个bug。由于我的设置很常见，我怀疑我可能做了一些愚蠢的事情（在经过两天的挣扎后变得更加不可能），或者人们根本就不在意。这不是一个边缘功能-只要在SO中搜索Git autocrlf就能看到。如果您能提供一些见解，将非常感激。 - Mr_and_Mrs_D

另一种方法是通过提供（使用补丁）对文档进行改进，以便正确的信息按照正确的顺序呈现。我知道Windows的行尾可能会成为一个真正的问题（我的问题：https://dev59.com/D1nUa4cB1Zd3GeqPb5lh）。 - Philip Oakley

显示剩余9条评论

2个回答

4

为了实现您的需求，我认为您需要以下步骤。请注意，根据GitAttributes手册，eol属性可以是"lf"或"crlf"。native用于core.eol配置设置。

设置core.autocrlf为false以显式控制归一化。现在只有标记为文本属性的文件才会进行归一化。

对于具体的文件类型（例如：shell脚本可能需要在unix上使用lf，.csproj文件可能需要在Windows上使用crlf），要么将eol属性明确地设置为lf或crlf，要么不设置eol属性并使用core.eol的值。如果将core.eol设置为crlf，则您的文本文件将使用crlf结束符。

以下是一个Git测试脚本来说明这一点（从git/t/运行）。

#!/bin/sh
test_description='check native crlf setting'
. ./test-lib.sh

has_cr() {
        tr '\015' Q <"$1" | grep Q >/dev/null
}

test_expect_success 'test native elf' '
  printf "*.txt text\n" > .gitattributes
  printf "one\r\ntwo\r\nthree\r\n" > filedos.txt
  printf "one\ntwo\nthree\n" > fileunix.txt
  git init &&
  git config core.autocrlf false &&
  git config core.eol crlf &&
  git add . &&
  git commit -m "first" &&
  rm file*.txt &&
  git reset --hard HEAD &&
  has_cr filedos.txt && has_cr fileunix.txt
'

test_done

通过上述配置和属性，在Git for Windows 1.8.0版本中，重置后两个文件都被规范化，并包含crlf行结尾。

可能存在的一个bug是，如果未设置core.eol变量（或将其设置为“native”），则此测试会失败，因为在这种情况下，文件会被规范化为lf行结尾。你提到的路径也无法解决这个问题。因此，从我的测试结果来看，你必须明确将core.eol设置为crlf，才能成功实现你的计划。

- patthoyts

谢谢 - 我之前曾将 eol=native 设置进去试图强制实现此操作。我知道将 eol=crlf 设置为使用 crlf 并且某些文件可能需要 lf 或 crlf 以工作（但我发布的这些文件没有）。但这是一个全时 bug：在 Windows 上，native 是 CRLF - 如果我把它放在我的 gitattributes 中，它就完全失去了目的 - 我的 Linux 合作者也会得到 CRLFs！使用 --global core.autocrlf 时情况好多了！！！必须解决这个问题 - 我重复一遍，通过在 Windows 上检出（通过 reset，checkout，clone 等方式）应该产生 CRLF，当 core.eol=native 时。 - Mr_and_Mrs_D

仔细看 - 如果您将这些文件的属性设置为“文本”，然后配置您的存储库以使用core.eol=crlf，那么您的Unix用户将拥有自己的core.eol设置（即：lf），并且它将适用于所有人。 core.eol = native目前不起作用 - 这是一个错误，我现在已经提出了修复建议，并应在下一个版本中解决。现在 - “git config core.eol crlf”并且根本不要在属性中设置eol。 - patthoyts

谢谢 - 我明白了 - 这就是我所说的 使用 --global core.autocrlf 时情况要好得多 - 我必须设置一个全局偏好，同时还要有 gitattributes（而以前只有全局的:）。请在您的回答中链接到您所做的错误报告/修复，以便我可以接受它。 - Mr_and_Mrs_D

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Mr_and_Mrs_D · Accepted Answer

这一定是一个错误。奇怪的是它没有被修复或报告 - 整个混乱都是关于Windows的，但它在Windows上不能正常工作？此外，似乎没有任何地方提到它（？）

编辑：从mingw的“最新存储库目录”安装 - g ++，gcc，ObjC + MinGW开发人员工具包和MSYS-1.0.11。同样的行为。每当我尝试提交CRLF文件时，我会收到CRLF将被替换为LF（在检出时隐含）警告。

编辑2：似乎即将被修复

编辑3：这已经在Git 1.8.4中修复。