git autocrlf 设置的最终建议

Definitive recommendation for git autocrlf settings

提问by rbellamy

I use Windows, Mac OS X and linux on a daily basis. I use git in all these environments, pulling from repos that are used by folks with different choices for line endings.

我每天都使用 Windows、Mac OS X 和 linux。我在所有这些环境中使用 git，从人们使用的 repos 中提取不同的行结尾选择。

Are there definitive recommendation for setting core.autocrlf in my situation?

在我的情况下是否有设置 core.autocrlf 的明确建议？

采纳答案by VonC

I would recommend, as I did in this SO question, to set it to false.

我会建议，就像我在这个SO question 中所做的那样，将其设置为 false。

If you can avoid modifying any eol (with your editor), then it would be best to push back your work with those eol unchanged (i.e. "as you found them").

如果您可以避免修改任何 eol（使用您的编辑器），那么最好在那些 eol 不变的情况下（即“如您所见”）推迟您的工作。

回答by John Broglio

One issue that is often not mentioned in these discussions: if you develop shell scripts on windows (say, in cygwin) and commit them with CRLF (autocrlf=false), they will crash on *nix boxes with useless error messages. (There may be similar cases with other scripting languages.) After scratching your head for a half-hour, you will remember and then dos2unix the little rascals. If you work in a mixed environment (say deploying from Windows to a linux server) and you absolutely want to set autocrlf to false, then MAKE SURE that all your windows editors use unix (lf) line endings. Otherwise set autocrlf to input (and pray). Most 21st Century Windows programs are comfortable without the early 1980's line printer CRs, so it's a good idea to set your line-endings to LF (unix) anyway.

在这些讨论中经常没有提到的一个问题：如果您在 Windows 上开发 shell 脚本（例如，在 cygwin 中）并使用 CRLF（autocrlf=false）提交它们，它们将在 *nix 框上崩溃并显示无用的错误消息。（其他脚本语言可能也有类似的情况。）摸了摸头半个小时，你会记得然后dos2unix这个小流氓。如果您在混合环境中工作（比如从 Windows 部署到 linux 服务器）并且您绝对希望将 autocrlf 设置为 false，那么请确保您的所有 Windows 编辑器都使用 unix (lf) 行结尾。否则将 autocrlf 设置为输入（并祈祷）。大多数 21 世纪的 Windows 程序在没有 1980 年代早期的行式打印机 CR 的情况下很舒服，因此无论如何将行结尾设置为 LF (unix) 是个好主意。

回答by Philip Oakley

GIT would NOT have common SHA1's for two text files with identicaltext but differentend-of-line(EOL) mechanisms inside the binary representation. The content is stored as a blob, which is reusedif another identicalcopy is de-posited into the re-pository (space saving!)

对于在二进制表示中具有相同文本但行尾 (EOL) 机制不同的两个文本文件，GIT 不会具有公共 SHA1 。内容存储为一个blob，这是重用如果另一个相同副本去假定为再pository（节省空间！）

The default choice taken by (the) GIT (designers) is to use the *nix style EOL character (LF only) whenever possible, so that for the same text contentyou get the same SHA1. (probably an important consideration ;-)

(the) GIT（设计者）的默认选择是尽可能使用 *nix 样式的 EOL 字符（仅限 LF），这样对于相同的文本内容，您将获得相同的 SHA1。（可能是一个重要的考虑因素；-）

Because the content/blob no longer remembers the user's original EOL choice (remember it's possibly now in some distant repository) , Git has to make some guesses (option based) about how to recreate the original user's file (was it CRLF or was it simply LF) in a manner that you (and your tools) can use.

因为内容/blob 不再记得用户的原始 EOL 选择（记住它现在可能在某个遥远的存储库中），Git 必须对如何重新创建原始用户的文件（是 CRLF 还是只是简单的）做出一些猜测（基于选项） LF）以您（和您的工具）可以使用的方式。

The normal recommendation is that locally each user (a) converts to *nix LF endings when committing into a blob (so all will see common SHA1 blob names) (a/k/a the Right Thing), and (b) locally set the re-creation option to their local system setting e.g. *nix(LF) or Windows(CRLF), etc.

通常的建议是本地每个用户 (a) 在提交到 blob 时转换为 *nix LF 结尾（因此所有人都会看到常见的 SHA1 blob 名称）（a/k/a the Right Thing），并且（b）在本地设置为其本地系统设置重新创建选项，例如 *nix(LF) 或 Windows(CRLF) 等。

Set some local standards for your users, and have the one big 'EOL/LF/CRLF & Whitespace Correction commit', and you'll be fine (plus training re-training of new users)

为你的用户设置一些本地标准，并有一个大的“EOL/LF/CRLF 和空白校正提交”，你会没事的（加上对新用户的培训再培训）

You can also make sure you (each user) uses a common white-space adjustment setting so that tabs v spaces, and trailing whitespaces doesn't cause more diffinconveniences!

您还可以确保您（每个用户）使用通用的空白调整设置，以便制表符与空格和尾随空白不会造成更多diff不便！