git autocrlf 设置的明确建议
我每天使用 Windows、Mac OS X 和 Linux。我在所有这些环境中使用 git，从具有不同行结尾选择的人们使用的存储库中提取。
对于我的情况，是否有设置 core.autocrlf 的明确建议？
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.
Are there definitive recommendation for setting core.autocrlf in my situation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我会推荐，就像我在这个 SO 问题，将其设置为 false。
如果您可以避免修改任何 eol（使用您的编辑器），那么最好在这些 eol 不变的情况下推迟您的工作（即“如您找到它们一样”）。
I would recommend, as I did in this SO question, to set it to 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").
这些讨论中经常没有提到的一个问题是：如果您在 Windows 上（例如，在 cygwin 中）开发 shell 脚本并使用 CRLF (autocrlf=false) 提交它们，它们将在 *nix 盒子上崩溃，并显示无用的错误消息。 （其他脚本语言也可能有类似的情况。） 挠头半个小时后，你就会想起然后dos2unix这些小流氓了。如果您在混合环境中工作（例如从 Windows 部署到 Linux 服务器）并且您绝对希望将 autocrlf 设置为 false，那么请确保所有 Windows 编辑器都使用 unix (lf) 行结尾。否则将 autocrlf 设置为输入（并祈祷）。大多数 21 世纪的 Windows 程序在没有 1980 年代早期的行式打印机 CR 的情况下也能正常工作，因此无论如何将行结束符设置为 LF (unix) 是个好主意。
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.
对于两个文本文件来说，GIT 不会有共同的 SHA1，其中两个文本文件的文本相同，但二进制表示中的行尾 (EOL) 机制不同。内容存储为 blob，如果将另一个相同副本存储到存储库中，则可以重用（节省空间！）
默认选择（ ) GIT（设计者）是尽可能使用 *nix 风格的 EOL 字符（仅限 LF），这样对于相同的文本内容，您将获得相同的 SHA1。 （可能是一个重要的考虑因素；-）
因为内容/blob 不再记住用户最初的 EOL 选择（记住它现在可能位于某个遥远的存储库中），Git 必须对如何重新创建原始用户的文件做出一些猜测（基于选项） （是 CRLF 还是只是 LF）以您（和您的工具）可以使用的方式。
通常的建议是，每个用户 (a) 在本地提交到 blob 时转换为 *nix LF 结尾（因此所有人都会看到常见的 SHA1 blob 名称）（a/k/a 正确的事情），并且 (b) 在本地设置为其本地系统设置重新创建选项，例如 *nix(LF) 或 Windows(CRLF) 等。
为您的用户设置一些本地标准，并有一个大的“EOL/LF/CRLF &”空白校正提交'，你会没事的（加上对新用户的重新培训）
您还可以确保您（每个用户）使用通用的空白调整设置，以便制表符 v 空格和尾随空白不会'不会造成更多
diff不便！GIT would NOT have common SHA1's for two text files with identical text but different end-of-line(EOL) mechanisms inside the binary representation. The content is stored as a blob, which is reused if another identical copy is de-posited into the re-pository (space saving!)
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 content you get the same SHA1. (probably an important consideration ;-)
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.
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.
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)
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!