问题标签 [core.autocrlf]

I've read a lot of different questions and answers on Stack Overflow as well as git documentation on how the core.autocrlf setting works.

This is my understanding from what I've read:

Unix and Mac OSX (pre-OSX uses CR) clients use LF line endings.
Windows clients use CRLF line endings.

When core.autocrlf is set to true on the client, the git repository always stores files in LF line ending format and line endings in files on the client are converted back and forth on check out / commit for clients (i.e. Windows) that use non-LF line endings, no matter what format the line endings files are on the client (this disagrees with Tim Clem's definition - see update below).

Here is a matrix that tries to document the same for the 'input' and 'false' settings of core.autocrlf with question marks where I'm not sure of line ending conversion behavior.

My questions are:

1. What should the question marks be?
2. Is this matrix correct for the "non-question marks"?

I'll update the question marks from the answers as consensus appears to be formed.

I'm not really looking for opinions on the pros and cons of the various settings. I'm just looking for data which makes it clear how to expect git to operate with each of the three settings.

--

Update 04/17/2012: After reading the article by Tim Clem linked by JJD in the comments, I have modified some of the values in the "unknown" values in the table above, as well as changing "checkout existing | true to convert to CRLF instead of convert to client". Here are the definitions he gives, which are more clear than anything I've seen elsewhere:

core.autocrlf = false

This is the default, but most people are encouraged to change this immediately. The result of using false is that Git doesn’t ever mess with line endings on your file. You can check in files with LF or CRLF or CR or some random mix of those three and Git does not care. This can make diffs harder to read and merges more difficult. Most people working in a Unix/Linux world use this value because they don’t have CRLF problems and they don’t need Git to be doing extra work whenever files are written to the object database or written out into the working directory.

core.autocrlf = true

This means that Git will process all text files and make sure that CRLF is replaced with LF when writing that file to the object database and turn all LF back into CRLF when writing out into the working directory. This is the recommended setting on Windows because it ensures that your repository can be used on other platforms while retaining CRLF in your working directory.

core.autocrlf = input

This means that Git will process all text files and make sure that CRLF is replaced with LF when writing that file to the object database. It will not, however, do the reverse. When you read files back out of the object database and write them into the working directory they will still have LFs to denote the end of line. This setting is generally used on Unix/Linux/OS X to prevent CRLFs from getting written into the repository. The idea being that if you pasted code from a web browser and accidentally got CRLFs into one of your files, Git would make sure they were replaced with LFs when you wrote to the object database.

Tim's article is excellent, the only thing I can think of that is missing is that he assumes the repository is in LF format, which is not necessarily true, especially for Windows only projects.

Comparing Tim's article to the highest voted answer to date by jmlane shows perfect agreement on the true and input settings and disagreement on the false setting.

在当前版本和下一个版本中，有很多关于 core.autocrlf 和 core.safecrlf 特性的讨论。我在这里遇到的问题与开发人员从裸存储库克隆的环境有关。

在克隆期间启用 autocrlf 设置。但是由于开发人员可以完全控制他们的克隆，他们可以删除这个 autocrlf 设置并继续。

1. 我们可以在 .gitattributes 文件中指定二进制文件以外的文件，但是 GIT 是否有其他方法自动确定文件是文本文件还是二进制文件？

2. 有没有办法像更新挂钩（提交挂钩是不可能的，因为开发人员仍然可以删除它）可以放置以确保文件（使用 CRLF）从 Windows 环境推送到托管裸仓库的 UNIX 机器，转换为 UNIX EOL 格式 (LF)？

3. 有这样的更新钩子来扫描每个文件的 CRLF 会影响推送操作的性能吗？

谢谢

这个问题有点类似于我的另一个问题， 确保文件在更新挂钩中被转换为 CRLF - 是否会影响性能？

所以这就是下面的架构所要寻找的。1. 我的父存储库（裸机和数据）位于 UNIX 机器上。2. 我可以在 UNIX 机器上克隆我的存储库。3. 我可以使用 samba 在 Windows 机器上克隆我的存储库以访问我的父存储库。

如果我如何处理 CRLF 问题

1. 用户在 UNIX 中创建克隆，使用 samba 将其映射到 Windows 驱动器，修改在 Windows 中完成，创建 CR/LF 字符对作为 EOL。如果用户回到 Unix 并提交和推送。GIT如何照顾？还是我们需要安装一些挂钩？

2. 与上面相同，但文件格式每行超过 8000 个字符 - 很多。这是否被视为 ASCII 文件，在提交时删除了 CR？

3. 2 的变体，但它是具有 ASCII 标头的二进制文件。这是否会无意中将 CR/LF 更改为 LF？

几乎每次我暂存一个文本文件（大部分是 em）时，我都会从 git gui（我使用 msysgit）收到消息，它用 CRLF 替换（或即将）行尾。显然我想要那个（并且有一个设置呼啦），但我不希望烦人的消息一直弹出！

有什么方法可以保留设置，但关闭/禁用弹出消息？

我不知道这如何在命令行上与 GIT 一起使用，但我喜欢 msysgit 的暂存过程 :) 所以我宁愿不改用 bash。

我现在有一个疑问，Git 是否在提交期间或文件期间进行 CRLF 转换vi？

假设我在 Windows 中有一些带有 CRLF 的文件（不是 Git 存储库），当我将这些文件同步到 UNIX Git 存储库并autocrlf true启用 git add/commit 时，这些文件会从 CRLF 转换为 LF 吗？

还是仅当我vi这些文件并再次提交时才转换这些文件？

第二个疑问是，如果我的父存储库存在于 Unix 中并且只需要 LF，那么 Unix 和 Windows Git 克隆中的autocrlf和设置应该是什么。safecrlf我应该使用全局设置吗？

提前致谢

我不明白 git: 中与 CrLf 设置相关的复杂性core.autocrlf：core.safecrlf

我正在一个团队中开发一个跨平台项目，并希望 Windows 和 Linux 开发人员能够一起工作，而无需 git 将文件标记为仅因为行结束样式而被修改。

各种设置是什么意思？选择任何选项会有什么后果？对于我的情况，最好的解决方案是什么？

是的，我知道这个问题，并且那里的答案没有洞察力，因此没有帮助。

有一系列令人眼花缭乱的选项可以通过 设置git config，而这只是记录在案的选项。在所有这些选项中，每个开发人员都应该在他们的盒子上设置哪些选项（如user.email）？core.autocrlf=input在常见情况下（如在 Windows 上）应该设置哪些最常见的？但请远离宗教争论（例如唯一可接受的core.whitespace存在设置tab-in-indent）。

即使在 Windows 上，Matlab .m 文件也使用 Unix LF 行尾。我希望设置 git 配置文件，以便 .m 文件不会像其他常规文本文件那样转换回 CRLF（即我使用 LF 作为 repo 中的默认样式，即使它的 Windows 也是如此）。

这可以做到吗？

编辑：来自 Matlab 2008b 手册。（在编辑和调试 M 文件下）

在 Windows 平台的 MATLAB 软件提供的文件中删除了行尾；影响记事本应用程序中的查看

在以前的版本中，MATLAB 为 Windows 平台提供的文本文件在每行的末尾包含一个回车符和换行符。从 R2007b 开始，MATLAB 提供的文本文件在每行末尾不包含回车和换行。

受影响的文件类型是： .asc .bat .c .cc .cdr .cpp .def .for gs.rights .h .ini .m .mdl .pl readme .tlc .tmf .txt

如果您在 MATLAB 和其他常用文本编辑器中查看文件，则不会产生任何影响，Microsoft Notepad 应用程序除外。

兼容性考虑。如果您使用记事本应用程序查看 MATLAB 提供的文件，您会看到回车符和换行符，而不是行尾。这使得文件在记事本应用程序中的可读性降低。其他文本编辑器可能会显示符号而不是行尾，但在测试的常见文本编辑器中，没有发现这样做的。

作为记事本应用程序的替代方案，使用随 Windows 平台提供的 Microsoft WordPad 应用程序或其他文本编辑器来查看文件。

我的老板和我是唯一在我们项目上工作的人，我们专门使用 Mac 进行开发。我们正在进行 groovy/grails 开发，并部署到 Linux 服务器。在我们的开发过程中任何地方都没有使用 MS Windows，但是不知何故，当我在 bash shell 中使用 git 比较文件时，我最终看到了那些^M表示 CR 的愚蠢字符（以及换行符，CRLF ）。

这突然出现在文件中。

我在网上搜索了将 IntelliJ IDEA 设置为仅使用 LF 作为行尾的位置，但找不到。在谷歌上搜索关于 IDEA 的答案的困难加剧了我在这里的挫败感。

我想做这些事情：

1. 在我的机器（OS X）上配置 git 以绝对拒绝任何 CRLF。

2. 此外，我使用 gitolite 作为我们中央存储库服务器（即 Ubuntu Linux）的访问层。如果可以在 gitolite 中强制拒绝 CRLF，那就更好了。

3. 将 IntelliJ IDEA 配置为从不将任何内容保存为 CRLF。如果可能的话，即使是现有的充满 CRLF 的文件，如果我添加这么多的空格并点击保存，所有CRLF 都会被剥离（转换为单个 LF）。

我认为自己通常非常精通 Git，但我对 CRLF 周围的所有配置感到非常困惑。有人能告诉我，对于我这个职位的人来说，所有这些设置应该是什么吗？

这里的要点是在纯粹的 *nix/LF 行结束环境中，我不想处理任何 CRLF 废话。这应该是绝对没有问题的，我讨厌处理它（以防你无法分辨）。

我希望 CRLF 永远离开我的生活，拜托。

我使用创建了我的存储库，autocrlf=true然后使用autocrlf=false. 然后切换回autocrlf=true（OS Win）。一切似乎都很好，直到我开始在分支之间进行一些合并。出现了许多合并冲突，其中整个文件被标记为因更改而更改eols（我想是那些文件，它们被签出并提交autocrlf=false）。

有一些历史，这对我来说是值得的，所以我更喜欢进行一些转换或修复提交，eols而不是创建新的 repo 并开始新的生活。

这就是我的理解autocrlf（OS Win）：

情况如果autocrlf=true

情况如果autocrlf=false

现在我想将 GIT 与. 一起使用autocrlf=false，所以我决定检查每个分支，使用实用程序EOL 转换器eols修复源文件并使用 CRLF 提交。我做到了，但是一段时间后，仍然有一些文件，在我将设置更改为之后可能没有检出（或者这些文件是从较旧的非固定提交合并而来的？在转换过程中，我使用掩码 *.filetype 来自动处理所有 LF 到 CRLF，所以对我来说这种情况没有其他解释）。我还尝试了文件，重新提交所有文件（正如我在stackoverflow中看到的那样），但日期更改与GIT AFAIK无关。我还阅读了如何撤消 autocrlf 的损坏autocrlffalsetouch，但不确定是我的情况，也不懂巫师的把戏。

请问我怎样才能摆脱这种混乱？