为什么我应该在 Git 中使用 core.autocrlf=true? [英] Why should I use core.autocrlf=true in Git?

问题描述

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

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:

1. 在任何地方将 core.autocrlf 设置为 false，

按照说明操作 此处(在 GitHub 的帮助页面上回显)将存储库转换为仅包含 LF 行结尾，然后将 core.autocrlf 设置为 true 在 Windows 上，input 在 OS X 上.这样做的问题是，如果我在存储库中有任何二进制文件:

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

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

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

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

那我为什么不直接关闭 Git 的行尾转换呢?网络上有很多关于关闭 core.autocrlf 会导致问题的模糊警告，但很少有特定；到目前为止，我发现的唯一问题是 kdiff3 无法处理 CRLF 结尾(对我来说不是问题)，并且某些文本编辑器存在行结尾问题(对我来说也不是问题).

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.autocrlf switched off causing problems, but very few specific ones; 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).

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

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.

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

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

推荐答案

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

The only specific reasons to set autocrlf to true are:

• 避免 git status 将所有文件显示为 modified，因为在将基于 Unix 的 EOL Git 存储库克隆到 Windows 存储库时会自动完成 EOL 转换(请参阅 问题 83 例如)
• 和您的编码工具在某种程度上取决于您的文件中存在的原生 EOL 样式:
  • 例如，硬编码的代码生成器用于检测原生 EOL
  • 使用正则表达式或代码集检测原生 EOL 的其他外部批次(在您的存储库之外)
  • 我相信一些 Eclipse 插件可以生成带有 CRLF 的文件，而不管平台如何，这可能是一个问题.
  • 您使用 Notepad.exe 进行编码 (除非您使用的是 Windows 10 2018.09+，其中记事本尊重检测到的 EOL 字符).
  • avoid git status showing all your files as modified because of the automatic EOL conversion done when cloning a Unix-based EOL Git repo to a Windows one (see issue 83 for instance)
  • and your coding tools somehow depends on a native EOL 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).

    除非您可以看到必须处理原生 EOL 的特定处理，否则您最好将 autocrlf 保留为 false (git config --global core.autocrlf false).

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

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

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

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

    If you want the same config for all users cloning that repo, check out "What's the best CRLF handling strategy with git?", using the text attribute in the .gitattributes file.

    示例:

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

    <小时>

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

    ---

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

    这篇关于为什么我应该在 Git 中使用 core.autocrlf=true?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！