为什么我应该在 Git 中使用 core.autocrlf=true？

Why should I use core.autocrlf=true in Git?

提问by Rich

I have a Git repository that is accessed from both Windows and OS X, and that I know already contains some files with CRLF line-endings. As far as I can tell, there are two ways to deal with this:

我有一个可以从 Windows 和 OS X 访问的 Git 存储库，我知道它已经包含一些带有 CRLF 行结尾的文件。据我所知，有两种方法可以解决这个问题：

1. Set core.autocrlfto falseeverywhere,

2. Follow the instructions here(echoed on GitHub's help pages) to convert the repository to contain only LF line-endings, and thereafter set core.autocrlfto trueon Windows and inputon OS X. The problem with doing this is that if I have any binary files in the repository that:

   1. are not correctly marked as binary in gitattributes, and
   2. happen to contain both CRLFs and LFs,

   they will be corrupted. It is possible my repository contains such files.

1. 设置core.autocrlf到false无处不在，

2. 按照此处的说明（在 GitHub 的帮助页面上回显）将存储库转换为仅包含 LF 行结尾，然后在 Windows 和OS X 上设置core.autocrlf为。 这样做的问题是，如果存储库中有任何二进制文件那：trueinput

   1. 在 gitattributes 中没有正确标记为二进制，并且
   2. 碰巧同时包含 CRLF 和 LF，

   他们会被破坏。我的存储库可能包含此类文件。

So why shouldn't I just turn off Git's line-ending conversion? There are a lot of vague warnings on the web about having core.autocrlfswitched off causing problems, but very few specificones; the only that I've found so far are that kdiff3 cannot handle CRLF endings (not a problem for me), and that some text editors have line-ending issues (also not a problem for me).

那么为什么我不应该关闭 Git 的行尾转换呢？网络上有很多关于core.autocrlf关闭导致问题的模糊警告，但很少有具体的警告；到目前为止，我发现的唯一问题是 kdiff3 无法处理 CRLF 结尾（对我来说不是问题），并且某些文本编辑器有行结尾问题（对我来说也不是问题）。

The repository is internal to my company, and so I don't need to worry about sharing it with people with different autocrlf settings or line-ending requirements.

该存储库是我公司内部的，因此我无需担心与具有不同 autocrlf 设置或行尾要求的人共享它。

Are there any other problems with just leaving line-endings as-is that I am unaware of?

仅保留行尾是否还有其他我不知道的问题？

采纳答案by VonC

The only specific reasons to set autocrlfto trueare:

设置autocrlf为的唯一具体原因true是：

• avoid git statusshowing all your files as modifiedbecause of the automatic EOL conversion done when cloning a Unix-based EOL Git repo to a Windows one (see issue 83for instance)
• andyour coding tools somehow depends on a nativeEOL style being present in your file:
  • for instance, a code generator hard-coded to detect native EOL
  • other external batches (external to your repo) with regexp or code set to detect native EOL
  • I believe some Eclipse plugins can produce files with CRLF regardless on platform, which can be a problem.
  • You code with Notepad.exe (unless you are using a Windows 10 2018.09+, where Notepad respects the EOL character detected).

• 避免git status将所有文件显示为modified因为在将基于 Unix 的 EOL Git 存储库克隆到 Windows 存储库时已完成自动 EOL 转换（例如，请参阅issue 83）
• 并且您的编码工具以某种方式取决于文件中存在的本机EOL 样式：
  • 例如，一个代码生成器硬编码来检测原生 EOL
  • 使用正则表达式或代码集检测本机 EOL 的其他外部批次（您的存储库外部）
  • 我相信一些 Eclipse 插件可以生成带有 CRLF 的文件，而不管平台如何，这可能是一个问题。
  • 您使用 Notepad.exe 进行编码（除非您使用的是 Windows 10 2018.09+，其中 Notepad 尊重检测到的 EOL 字符）。

Unless you can see specific treatment which mustdeal with native EOL, you are better off leaving autocrlfto false(git config --global core.autocrlf false).

除非你能看到哪些具体的治疗必须应对本土停产，你最好留下autocrlf来false（git config --global core.autocrlf false）。

Note that this config would be a localone (because config isn't pushed from repo to repo)

请注意，此配置将是本地配置（因为配置不会从 repo 推送到 repo）

If you want the same config for all users cloning that repo, check out "What's the best CRLFhandling strategy with git?", using the textattribute in the .gitattributesfile.

如果您希望克隆该存储库的所有用户使用相同的配置，请查看“ git的最佳CRLF处理策略是什么？”，使用文件中的text属性。.gitattributes

Example:

例子：

*.vcproj    text eol=crlf
*.sh        text eol=lf

---

---

Note: starting git 2.8 (March 2016), merge markers will no longerintroduce mixed line ending (LF) in a CRLF file.
See "Make Git use CRLF on its “<<<<<<< HEAD” merge lines"

注意：从 git 2.8（2016 年 3 月）开始，合并标记将不再在 CRLF 文件中引入混合行尾 (LF)。
请参阅“让 Git 在其“<<<<<<< HEAD”合并行上使用 CRLF”

回答by JGTaylor

I am a .NET developer, and have used Git and Visual Studio for years. My strong recommendation is set line endings to true. And do it as early as you can in the lifetime of your Repository.

我是一名 .NET 开发人员，多年来一直使用 Git 和 Visual Studio。我强烈建议将行尾设置为 true。并在存储库的生命周期内尽早完成。

That being said, I HATE that Git changes my line endings. A source control should only save and retrieve the work I do, it should NOT modify it. Ever. But it does.

话虽如此，我讨厌 Git 更改我的行尾。源代码管理应该只保存和检索我所做的工作，而不应该修改它。曾经。但确实如此。

What will happen if you don't have every developer set to true, is ONE developer eventually will set to true. This will begin to change the line endings of all of your files to LF in your repo. And when users set to false check those out, Visual Studio will warn you, and ask you to change them. You will have 2 things happen very quickly. One, you will get more and more of those warnings, the bigger your team the more you get. The second, and worse thing, is that it will show that every line of every modified file was changed(because the line endings of every line will be changed by the true guy). Eventually you won't be able to track changes in your repo reliably anymore. It is MUCH easier and cleaner to make everyone keep to true, than to try to keep everyone false. As horrible as it is to live with the fact that your trusted source control is doing something it should not. Ever.

如果您没有将每个开发人员都设置为 true 会发生什么，一个开发人员最终会设置为 true。这将开始将您的所有文件的行尾更改为 LF。当用户设置为 false 检查这些时，Visual Studio 会警告您，并要求您更改它们。你会很快发生两件事。一，你会收到越来越多的警告，你的团队越大，你得到的就越多。第二，更糟糕的是，它会显示每个修改过的文件的每一行都被改变了（因为每一行的行尾都会被真正的人改变）。最终，您将无法再可靠地跟踪存储库中的更改。让每个人都保持真实比试图让每个人都保持虚假要容易和干净得多。忍受这样一个事实，即您信任的源代码控制正在做它不应该做的事情，这真是太可怕了。曾经。

回答by Rich

Update 2:

更新2：

Xcode 9 appears to have a "feature" where it will ignore the file's current line endings, and instead just use your default line-ending setting when inserting lines into a file, resulting in files with mixed line endings.

Xcode 9 似乎有一个“功能”，它会忽略文件的当前行尾，而是在将行插入文件时使用默认的行尾设置，从而导致文件具有混合行尾。

I'm pretty sure this bug didn't exist in Xcode 7; not sure about Xcode 8. The good news is that it appears to be fixed in Xcode 10.

我很确定这个错误在 Xcode 7 中不存在；不确定 Xcode 8。好消息是它似乎已在 Xcode 10 中修复。

For the time it existed, this bug caused a small amount of hilarity in the codebase I refer to in the question (which to this day uses autocrlf=false), and led to many "EOL" commit messages and eventually to my writing a git pre-commithook to check for/prevent introducing mixed line endings.

在它存在的时候，这个错误在我在问题中提到的代码库中引起了少量的欢笑（直到今天还在使用autocrlf=false），并导致了许​​多“EOL”提交消息，并最终导致我编写了一个 git pre-commithook 来检查用于/防止引入混合行尾。

Update:

更新：

Note: As noted by VonC, starting from Git 2.8, merge markers will notintroduce Unix-style line-endings to a Windows-style file.

注：由于注意到VonC，从Git的2.8开始，合并标记将不会推出Unix风格的行结束到Windows样式的文件。

Original:

原文：

One little hiccup that I've noticed with this setup is that when there are merge conflicts, the lines git adds to mark up the differences do nothave Windows line-endings, even when the rest of the file does, and you can end up with a file with mixed line endings, e.g.:

我注意到这个设置的一个小问题是，当出现合并冲突时，git 添加来标记差异的行没有Windows 行尾，即使文件的其余部分有，你也可以结束带有混合行尾的文件，例如：

// Some code<CR><LF>
<<<<<<< Updated upstream<LF>
// Change A<CR><LF>
=======<LF>
// Change B<CR><LF>
>>>>>>> Stashed changes<LF>
// More code<CR><LF>

This doesn't cause us any problems (I imagine any tool that can handle both types of line-endings will also deal sensible with mixed line-endings--certainly all the ones we use do), but it's something to be aware of.

这不会给我们带来任何问题（我想任何可以处理两种类型的行尾的工具也可以处理混合行尾——当然我们使用的所有那些都这样做），但这是需要注意的。

The other thing^*we've found, is that when using git diffto view changes to a file that has Windows line-endings, lines that have been added display their carriage returns, thus:

另一件事^*我们发现，是使用时git diff查看更改了Windows行结束，已添加施展回车，这样行的文件：

    // Not changed

+   // New line added in^M
+^M
    // Not changed
    // Not changed

_{* It doesn't really merit the term: "issue".}

_{* 它真的不值得这个词：“问题”。}