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

问题描述

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

1. 设置核心。 autocrlf 到 false 无处不在，

按照说明这里（回声在GitHub的帮助页面上）将存储库转换为仅包含LF行结束符，然后将 core.autocrlf 设置为 true ，在OS X上是 input 。这样做的问题是，如果我在存储库中有任何二进制文件：


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



它们将被破坏。这可能是我的存储库包含这样的文件。

那么为什么我不应该关闭Git的换行转换？网上有很多含糊不清的警告，关于 core.autocrlf 关闭导致问题，但很少有特定的;到目前为止我发现的唯一情况是kdiff3无法处理CRLF结局（对我来说不是问题），并且一些文本编辑器有行结束的问题（对我来说也不是问题）。



存储库是我公司的内部存储库，因此我不必担心与具有不同autocrlf设置或行结束要求的人共享存储库。

是否有任何其他问题，只是离开行结束 - 因为我不知道？

解决方案

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

• 避免 git status 显示您的所有文件为修改，因为EOL自动转换在将基于Unix的EOL Git仓库克隆到Windows仓库时完成（参见 issue 83 ）


• and your codi ng工具以某种方式依赖于文件中存在的本地 EOL样式：例如，
  
  
  
  
  • 代码生成器硬编码为使用正则表达式或代码集检测本地EOL
  
  
  • 我相信一些Eclipse插件可以生成其他外部批次（在您的repo外部）无论在平台上如何使用CRLF文件，这可能是一个问题。
  
  

可以看到必须处理本地EOL的具体处理，您最好不要使用将 autocrlf 留给 false 。

请注意，此配置将是一个本地一个（因为配置不会从回购推到回购）

如果你想要克隆该回购所有用户的配置相同，请查看什么是使用 文本的最佳 CRLF 使用git的处理策略？ / code> 属性的 .gitattributes 文件。

---

注意： ），合并标记将不再在CRLF文件中引入混合行尾（LF）。

请参阅让Git在其<<<<<<<<<< HEAD合并行

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. Set core.autocrlf to false everywhere,

2. 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. are not correctly marked as binary in gitattributes, and
   2. happen to contain both CRLFs and LFs,

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

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).

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?

解决方案

The only specific reasons to set autocrlf to true are:

• 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.

Unless you can see specific treatment which must deal with native EOL, you are better off leaving autocrlf to false.

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

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.

---

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屋！