Question

我决定通过.gitattributes文件将我的行结束设置为正确的方式，例如here的详细信息 - 所以我将core.autocrlf设置为false并创建并提交了.gitattributes文件：< / p>

*.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

然后我按照建议here发布了git rm --cached -r .然后git reset --hard（也尝试了git checkout HEAD）。现在所有文件都有LF行结尾。不应该是CRLF？我错过了什么？我在Windows 7上，git version 1.8.0.msysgit.0。

由于

Answer 1

必须是bug。奇怪的是它没有固定或报告真的 - 这整个混乱是关于窗口，它不能正确地在Windows上工作？此外，在任何地方都没有提到它（？）

编辑：安装在mingw＆＃34;最新的存储库目录＆＃34; - g ++，gcc，ObjC + MinGW Developer Toolkit和MSYS-1.0.11。相同的行为。每当我尝试提交CRLF文件时，我都会将 CRLF替换为LF （在结账时隐含）警告。

编辑2：seems即将修复

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

Answer 2

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

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

将eol属性显式设置为lf或crlf用于特定的文件类型（例如：shell脚本可能需要lf才能在unix上工作，.csproj文件可能需要在windows上使用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行结尾。

如果可能存在错误，如果core.eol变量未设置（或设置为“native”），则此测试将失败，因为在这种情况下文件被标准化为lf行结尾。你上面提到的路径也没有帮助这种情况。因此，从我的测试中，您必须明确地将core.eol设置为crlf，以使您的计划方法成功。

git line endings：renormalize似乎没有检查右边的结尾

2 个答案: