【问题标题】:git line endings : renormalize does not seem to checkout the right line endingsgit line endings : renormalize 似乎没有检出正确的行尾
【发布时间】:2012-11-23 15:31:31
【问题描述】:

我决定通过.gitattributes 文件将行尾设置为正确的方式,例如here - 所以我将 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),正如here所建议的那样。现在所有文件都有 LF 行结尾。不应该是 CRLF 吗?我想念什么?我在 Windows 7 上,git version 1.8.0.msysgit.0

谢谢

【问题讨论】:

  • @VonC :我发布了rm .git/index 然后git reset 但没有任何改变-我已经提交了gitattributes-无论如何奇怪的是checkout应该结帐Windows行结尾-我想念什么?我写的 gitattributes 好像没问题吧?
  • @VonC :我回滚并按照程序无济于事 - 坚持使用 unix 行结尾检查
  • @VonC :显然是一个错误 - 请参阅下面的答案(并根据需要进行编辑 - 没有时间正确报告错误)
  • @patthoyts:我刚刚看到你与 git 有关,所以我会回答你的评论 - 我通常不会因为我不喜欢被光顾。我没有说我不会报道,我说我没有。然而,我确实回答了 git 邮件列表中的一个 2 岁线程,其中尽可能清楚地报告了该错误。由于我的设置并不罕见,我要么怀疑我做了一些愚蠢的事情(经过 2 天的挣扎之后变得更不可能),要么人们根本不在乎。这不是一个边缘功能 - 只需搜索 git autocrlf。如果您能提供一些见解,我们将不胜感激。

标签: git line-endings gitattributes


【解决方案1】:

它必须是bug。奇怪的是它并没有真正修复或报告 - 这整个混乱都是关于 Windows 的,它不能在 Windows 上精确工作?此外,任何地方都没有提到它(?)

编辑:从 mingw“最新存储库目录”安装 - g++、gcc、ObjC + MinGW Developer Toolkit 和 MSYS-1.0.11。相同的行为。每当我尝试提交 CRLF 文件时,我都会收到 CRLF 将被替换为 LF(在结帐时暗示)警告。

编辑 2:seems 即将修复

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

【讨论】:

  • +1 反馈。如果我重现该问题,我将在我这边进行测试。
  • @VonC: 非常感谢 - 请注意我在 mingwin 上(详细信息如下:comments.gmane.org/gmane.comp.version-control.git/148436
  • 我不知道它是否有帮助,但我按照here 的说明取得了一些成功:当在现有存储库中启用 text=auto normalization 时,任何包含CRLF 应该被标准化。如果它们不是,那么下次有人试图改变它们时,它们将被标准化,从而导致不幸的错误归因。从一个干净的工作目录:...
  • @ta.speot.is:谢谢 - 我也试过了 - 请参阅我的问题中的 comment
  • 这个bug终于在Git for Windows 1.8.4修复了。
【解决方案2】:

对于您正在尝试做的事情,我认为您需要以下内容。请注意,根据 gitattributes 手册页的 eol 属性可能是“lf”或“crlf”。 Native 用于 core.eol 配置设置。

将 core.autocrlf 设置为 false 以显式控制规范化。现在只有用 text 属性标记的文件才会进行规范化。

针对特定文件类型将 eol 属性显式设置为 lf 或 crlf(例如:shell 脚本可能需要 lf 才能在 unix 上工作,.csproj 文件可能需要 crlf 在 Windows 上)。如果未设置 eol 属性,则应使用 core.eol 的值。如果您将 core.eol 设置为 crlf,那么您的文本文件将以 crlf 结尾。

这是一个 git 测试脚本来说明这一点(从 gi​​t/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

使用上述配置和属性,对于 Windows 1.8.0 的 Git,这两个文件在重置后都被规范化并包含 crlf 行结尾。

可能存在的错误是,如果 core.eol 变量未设置(或设置为“本机”),则此测试将失败,因为在这种情况下文件被规范化为 lf 行结尾。您上面提到的路径也无助于这种情况。因此,根据我的测试,您必须将 core.eol 显式设置为 crlf 才能使您计划的方法成功。

【讨论】:

  • 谢谢 - 我已经把 eol=native 放在试图强迫这个。我知道设置eol=crlf 将使结帐使用crlf,并且某些文件可能需要lf 或crlf 才能工作(尽管我发布的都没有)。但这是一个全职错误:在 Windows 上 native 是 CRLF - 如果我把它放在我的 gitattributes 中,它完全违背了它的目的 - 我的 linux 合作者也会得到 CRLF!然后--global core.autocrlf 的情况好多了!!!这必须修复 - 我在 Windows 上重复检查(通过 reset, checkout, clone etc)应该在 core.eol=native 时产生 CRLF
  • 仔细查看 - 如果您将这些文件的属性设置为“文本”,然后将存储库配置为使用 core.eol=crlf,那么您的 unix 用户将拥有自己的 core.eol 设置(即: lf) 它适用于所有人。 core.eol = native 目前不工作 - 这是一个我现在提出修复的错误,应该在下一个版本中解决。现在 - 'git config core.eol crlf' 并且根本不要在属性中设置 eol。
  • 谢谢 - 我明白了 - 这就是我的意思 使用 --global core.autocrlf 然后情况要好得多 - 我必须将全局偏好设置为它是 and 有 gitattributes (而之前它只是一个全局的:)。请链接到您在答案中所做的错误报告/修复,以便我接受。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2019-06-14
  • 1970-01-01
  • 2023-03-27
  • 2010-09-08
  • 2016-12-26
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多