Windows上的Git：crlf设置是什么意思？ [英] Git on Windows: What do the crlf settings mean?

问题描述

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

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

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

是的，我知道

> autocrlf 的三个值：

当内容进入存储库时，其行结尾将转换为LF，但内容在出路时保持不变。这与 true 基本处于相同的领域，假定编辑者实际上可以正确处理LF结尾;您只是在防范意外创建带有CRLF结尾的文件。
git根本不涉及行结尾。随你便。这是很多人推荐的。通过这个设置，如果文件的行结尾会被混淆，你必须知道它，所以合并冲突的可能性要小得多（假设知情用户）。教育开发人员如何使用他们的编辑器/ IDE几乎可以解决这个问题。如果配置正确，所有我见过的编程人员都可以处理这个问题。

请注意， autocrlf 不会影响存储库中 的内容。如果您之前已经提交了CRLF结局，他们会保持这种状态。这是避免依赖autocrlf的一个很好的理由;如果一个用户没有设置它们，他们可以将CRLF结尾的内容放入回购站，并且会坚持下去。更强大的标准化方法是使用文本属性;把它设置为 auto 给定的路径将标记为行结束标准化，假设git决定内容是文本（不是二进制）。

相关的选项是 safecrlf ，这基本上就是确保您不会在二进制文件上不可逆转地执行CRLF转换的一种方法。

我没有很多处理Windows问题和git的经验，所以我们欢迎有关暗示/陷阱的反馈。

I don't understand the complexities related to CrLf settings in git: core.autocrlf, core.safecrlf

I'm developing a cross-platform project in a team and would like both Windows and Linux developers to be able to work together without git marking files as modified just because of line ending style.

What do the various settings mean? What would be the consequences of choosing any of the options? And what would be the best solution for my case?

Yes, I'm aware of this question and the answers there were not insightful, thus not helpful.

解决方案

The three values for autocrlf:

• true - when content goes into the repository (is committed), its line endings will be converted to LF, and when content comes out of the repository (is checked out), the line endings be converted to CRLF. This is in general meant for clueless windows users/editors. Given the assumption that an editor (or user) is going to create files with CRLF endings, and will freak out if it sees normal LF endings, but that you want LF endings in the repo, this will hopefully cover you. It's possible for things to go awry, though. There are examples of spurious merge conflicts and reports of modified files in the linked questions.

• input - when content goes into the repository, its line endings will be converted to LF, but content is left untouched on the way out. This is basically in the same realm as true, with the assumption that the editors actually can deal with LF endings correctly; you're just guarding against the possibility of accidentally creating a file with CRLF endings.

• false - git doesn't deal with line endings at all. It's up to you. This is what a lot of people recommend. With this setting, if a file's line endings are going to be messed with, you'll have to be aware of it, so merge conflicts are a lot less likely (assuming informed users). Educating developers about how to use their editors/IDEs can pretty much take care of the problem. All of the editors I've seen designed for programmers are capable of dealing with this if configured properly.

Note that autocrlf will not affect content which is already in the repository. If you've committed something with CRLF endings previously, they'll stay that way. This is a very good reason to avoid depending on autocrlf; if one user doesn't have it set, they can get content with CRLF endings into the repo, and it'll stick around. A stronger way to force normalization is with the text attribute; setting it to auto for a given path will mark it for end-of-line normalization, assuming git decides the content is text (not binary).

A related option is safecrlf, which is basically just a way to make sure you don't irreversably perform CRLF conversion on a binary file.

I don't have a ton of experience dealing with Windows issues and git, so feedback about implications/pitfalls is certainly welcome.

这篇关于Windows上的Git：crlf设置是什么意思？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！