git 用 CRLF 替换 LF

git replacing LF with CRLF

提问by mrblah

Running git on a Windows XP machine, using bash. I exported my project from SVN, and then cloned a bare repository.

使用 bash 在 Windows XP 机器上运行 git。我从 SVN 导出了我的项目，然后克隆了一个裸存储库。

I then pasted the export into the bare repositories directory, and did a:

然后我将导出粘贴到裸存储库目录中，并执行了以下操作：

git add -A

I then got a list of messages saying:

然后我得到了一个消息列表，上面写着：

LF will be replaced by CRLF

LF 将被 CRLF 取代

What are the ramifications of this conversion? This is a .NET solution in Visual Studio.

这种转换的后果是什么？这是 Visual Studio 中的 .NET 解决方案。

回答by Antony Hatchkins

These messages are due to incorrect default value of core.autocrlfon Windows.

这些消息是由于core.autocrlfWindows 上的默认值不正确造成的。

The concept of autocrlfis to handle line endings conversions transparently. And it does!

的概念autocrlf是透明地处理行尾转换。确实如此！

Bad news: value needs to be configured manually.
Good news: it should only be done ONE time per git installation (per project setting is also possible).

坏消息：需要手动配置值。
好消息：每个 git 安装应该只完成一次（每个项目设置也是可能的）。

How autocrlfworks:

如何autocrlf工作：

core.autocrlf=true:      core.autocrlf=input:     core.autocrlf=false:

        repo                     repo                     repo
      ^      V                 ^      V                 ^      V
     /        \               /        \               /        \
crlf->lf    lf->crlf     crlf->lf       \             /          \      
   /            \           /            \           /            \

Here crlf= win-style end-of-line marker, lf= unix-style (and mac osx).

这里crlf= win 风格的行尾标记，lf= unix 风格（和 mac osx）。

(pre-osx crin not affected for any of three options above)

（cr上述三个选项中的任何一个都不会影响预 osx ）

When does this warning show up (under Windows)

此警告何时出现（在 Windows 下）

    – autocrlf= trueif you have unix-style lfin one of your files (= RARELY),
    – autocrlf= inputif you have win-style crlfin one of your files (= almost ALWAYS),
    – autocrlf= false– NEVER!

    – autocrlf=true如果您lf的文件之一中有 unix 样式（= 很少），
    – autocrlf=input如果您crlf的文件之一中有 win 样式（= 几乎总是），
    – autocrlf= false– 永远不会！

What does this warning mean

这个警告是什么意思

The warning "LF will be replaced by CRLF" says that you (having autocrlf=true) will lose your unix-style LF after commit-checkout cycle (it will be replaced by windows-style CRLF). Git doesn't expect you to use unix-style LF under windows.

警告“ LF 将被 CRLF 替换”表示您（拥有autocrlf= true）将在提交结账周期后丢失您的 unix 风格的 LF（它将被 Windows 风格的 CRLF 取代）。Git 不希望你在 windows 下使用 unix 风格的 LF。

The warning "CRLF will be replaced by LF" says that you (having autocrlf=input) will lose your windows-style CRLF after a commit-checkout cycle (it will be replaced by unix-style LF). Don't use inputunder windows.

警告“ CRLF 将被 LF 替换”表示您（拥有autocrlf= input）将在提交-结帐周期后丢失 Windows 风格的 CRLF（它将被 unix 风格的 LF 替换）。不要input在窗户下使用。

Yet another way to show how autocrlfworks

展示autocrlf工作原理的另一种方式

1) true:             x -> LF -> CRLF
2) input:            x -> LF -> LF
3) false:            x -> x -> x

where xis either CRLF (windows-style) or LF (unix-style) and arrows stand for

其中x是 CRLF（windows 风格）或 LF（unix 风格），箭头代表

file to commit -> repository -> checked out file

How to fix

怎么修

Default value for core.autocrlfis selected during git installation and stored in system-wide gitconfig (%ProgramFiles(x86)%\git\etc\gitconfig). Also there're (cascading in the following order):

core.autocrlf在 git 安装期间选择的默认值并存储在系统范围的 gitconfig ( %ProgramFiles(x86)%\git\etc\gitconfig) 中。还有（按以下顺序级联）：

   – "global" (per-user) gitconfig located at ~/.gitconfig, yet another
   – "global" (per-user) gitconfig at $XDG_CONFIG_HOME/git/configor $HOME/.config/git/configand
   – "local" (per-repo) gitconfig at .git/configin the working dir.

   – "global" (per-user) gitconfig at ~/.gitconfig, 还有一个
   – "global" (per-user) gitconfig at $XDG_CONFIG_HOME/git/configor$HOME/.config/git/config和
   – "local" (per-repo) gitconfig at at .git/configthe working dir。

So, write git config core.autocrlfin the working dir to check the currently used value and

因此，写入git config core.autocrlf工作目录以检查当前使用的值和

   – add autocrlf=falseto system-wide gitconfig         # per-system solution
   – git config --global core.autocrlf false           # per-user solution
   – git config --local core.autocrlf false             # per-project solution

   – 添加autocrlf=false到系统范围的 gitconfig # 每个系统解决方案
   – git config --global core.autocrlf false           # 每个用户解决方案
   – git config --local core.autocrlf false             # 每个项目解决方案

Warnings
– git configsettings can be overridden by gitattributessettings.
– crlf -> lfconversion only happens when adding new files, crlffiles already existing in the repo aren't affected.

警告
-git config设置可以被gitattributes设置覆盖。
–crlf -> lf转换仅在添加新文件时发生，crlfrepo 中已存在的文件不受影响。

Moral(for Windows):
    - use core.autocrlf= trueif you plan to use this project under Unix as well (and unwilling to configure your editor/IDE to use unix line endings),
    - use core.autocrlf= falseif you plan to use this project under Windows only (or you have configured your editor/IDE to use unix line endings),
    - neveruse core.autocrlf= inputunless you have a good reason to (egif you're using unix utilities under windows or if you run into makefiles issues),

道德（适用于Windows）：
    -使用core.autocrlf=true如果您计划使用该项目在Unix下，以及（和不愿配置编辑器/ IDE使用Unix行结尾），
    -使用core.autocrlf=false如果你打算只（使用这个项目在Windows下或者您已将您的编辑器/IDE 配置为使用 unix 行尾），
    - 除非您有充分的理由（例如，如果您在 Windows 下使用 unix 实用程序或遇到 makefile 问题），否则不要使用core.autocrlf= ，input

PS What to choose when installing git for Windows?
If you're not going to use any of your projects under Unix, don'tagree with the default first option. Choose the third one (Checkout as-is, commit as-is). You won't see this message. Ever.

PS安装 git for Windows 时要选择什么？
如果您不打算在 Unix 下使用任何项目，请不要同意默认的第一个选项。选择第三个（按原样结帐，按原样提交）。您不会看到此消息。曾经。

PPS My personal preference is configuring the editor/IDEto use Unix-style endings, and setting core.autocrlfto false.

PPS 我个人的偏好是将编辑器/IDE配置为使用 Unix 风格的结尾，并设置core.autocrlf为false.

回答by Andrew Arnott

Git has three modes of how it treats line endings:

Git 有三种处理行尾的模式：

$ git config core.autocrlf
# that command will print "true" or "false" or "input"

You can set the mode to use by adding an additional parameter of trueor falseto the above command line.

您可以通过向上述命令行添加true或的附加参数来设置要使用的模式false。

If core.autocrlfis set to true, that means that any time you add a file to the git repo that git thinks is a text file, it will turn all CRLF line endings to just LF before it stores it in the commit. Whenever you git checkoutsomething, all text files automatically will have their LF line endings converted to CRLF endings. This allows development of a project across platforms that use different line-ending styles without commits being very noisy because each editor changes the line ending style as the line ending style is always consistently LF.

如果core.autocrlf设置为 true，这意味着任何时候你将一个文件添加到 git 仓库中，git 认为它是一个文本文件，它会将所有 CRLF 行结尾转换为 LF，然后将其存储在提交中。无论何时git checkout，所有文本文件都会自动将它们的 LF 行结尾转换为 CRLF 结尾。这允许跨使用不同行尾样式的平台开发项目，而不会提交非常嘈杂，因为每个编辑器都会更改行尾样式，因为行尾样式始终为 LF。

The side-effect of this convenient conversion, and this is what the warning you're seeing is about, is that if a text file you authored originally had LF endings instead of CRLF, it will be stored with LF as usual, but when checked out later it will have CRLF endings. For normal text files this is usually just fine. The warning is a "for your information" in this case, but in case git incorrectly assesses a binary file to be a text file, it is an important warning because git would then be corrupting your binary file.

这种方便转换的副作用，这就是您所看到的警告，是如果您最初创作的文本文件具有 LF 结尾而不是 CRLF，它将像往常一样与 LF 一起存储，但在检查时稍后它会有 CRLF 结尾。对于普通的文本文件，这通常很好。在这种情况下，警告是“供您参考”，但如果 git 错误地将二进制文件评估为文本文件，这是一个重要的警告，因为 git 会破坏您的二进制文件。

If core.autocrlfis set to false, no line-ending conversion is ever performed, so text files are checked in as-is. This usually works ok, as long as all your developers are either on Linux or all on Windows. But in my experience I still tend to get text files with mixed line endings that end up causing problems.

如果core.autocrlf设置为 false，则不会执行任何行结束转换，因此将按原样检入文本文件。这通常可以正常工作，只要您的所有开发人员都在 Linux 上或都在 Windows 上。但根据我的经验，我仍然倾向于得到带有混合行尾的文本文件，最终导致问题。

My personal preference is to leave the setting turned ON, as a Windows developer.

作为 Windows 开发人员，我个人的偏好是将设置保持打开状态。

See http://kernel.org/pub/software/scm/git/docs/git-config.htmlfor updated info that includes the "input" value.

有关包含“输入”值的更新信息，请参阅http://kernel.org/pub/software/scm/git/docs/git-config.html。

回答by user2630328

If you already have checked out the code, the files are already indexed. After changing your git settings, say by running:

如果您已经签出代码，则文件已经编入索引。更改 git 设置后，请运行以下命令说：

git config --global core.autocrlf input 

you should refresh the indexes with

你应该刷新索引

git rm --cached -r . 

and re-write git index with

并用

git reset --hard

https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings

https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changed-line-endings

Note: this is will remove your local changes, consider stashing them before you do this.

注意：这将删除您的本地更改，请在执行此操作之前考虑将其隐藏。

回答by Arun

git config core.autocrlf false

回答by Rifat

Both unix2dosand dos2unixis available in windows with gitbash. You can use the following command to perform UNIX(LF) -> DOS(CRLF) conversion. Hence, you will not get the warning.

无论unix2dos和DOS2UNIX的是与gitbash窗口可用。您可以使用以下命令执行 UNIX(LF) -> DOS(CRLF) 转换。因此，您不会收到警告。

unix2dos filename

or

或者

dos2unix -D filename

But, don't run this command on any existing CRLF file, then you will get empty newlines every second line.

但是，不要在任何现有的 CRLF 文件上运行此命令，否则每两行你都会得到一个空的换行符。

dos2unix -D filenamewill not work with every operating system. Please check this linkfor compatibility.

dos2unix -D filename不适用于所有操作系统。请检查此链接以了解兼容性。

If for some reason you need to force the command then use --force. If it says invalid then use -f.

如果由于某种原因您需要强制执行该命令，请使用--force. 如果它说无效，则使用-f.

回答by Yevgeny Simkin

I think @Basiloungas's answeris close but out of date (at least on Mac).

我认为@Basiloungas 的答案很接近但已经过时（至少在 Mac 上）。

Open the ~/.gitconfig file and set safecrlfto false

打开 ~/.gitconfig 文件并设置safecrlf为 false

[core]
       autocrlf = input
       safecrlf = false

That *will make it ignore the end of line char apparently (worked for me, anyway).

那 * 显然会使其忽略行尾字符（无论如何对我有用）。

回答by Gene Pavlovsky

A GitHub's article on line endingsis commonly mentioned when talking about this topic.

一个GitHub的就行结束文章谈论这个话题时，通常提及。

My personal experience with using the often recommended core.autocrlfconfig setting was very mixed.

我个人使用经常推荐的core.autocrlf配置设置的经验非常复杂。

I'm using Windows with Cygwin, dealing with both Windows and UNIX projects at different times. Even my Windows projects sometimes use bashshell scripts, which require UNIX (LF) line endings.

我将 Windows 与 Cygwin 一起使用，在不同时间处理 Windows 和 UNIX 项目。甚至我的 Windows 项目有时也使用bashshell 脚本，这需要 UNIX (LF) 行结尾。

Using GitHub's recommended core.autocrlfsetting for Windows, if I check out a UNIX project (which does work perfectly on Cygwin - or maybe I'm contributing to a project that I use on my Linux server), the text files are checked out with Windows (CRLF) line endings, creating problems.

使用 GitHubcore.autocrlf为 Windows推荐的设置，如果我签出一个 UNIX 项目（它在 Cygwin 上运行良好 - 或者我正在为我在 Linux 服务器上使用的项目做出贡献），文本文件将使用 Windows 签出（CRLF ) 行结尾，产生问题。

Basically, for a mixed environment like I have, setting the global core.autocrlfto any of the options will not work well in some cases. This option might be set on a local (repository) git config, but even that wouldn't be good enough for a project that contains both Windows- and UNIX-related stuff (e.g. I have a Windows project with some bashutility scripts).

基本上，对于像我这样的混合环境，将全局设置core.autocrlf为任何选项在某些情况下都无法正常工作。这个选项可能在本地（存储库）git 配置上设置，但即使对于包含 Windows 和 UNIX 相关内容的项目（例如，我有一个带有一些bash实用程序脚本的 Windows 项目）的项目来说，这也不够好。

The best choice I've found is to create per-repository .gitattributesfiles. The GitHub articlementions it.
Example from that article:

我发现的最佳选择是创建每个存储库的.gitattributes文件。在GitHub的文章提到它。
那篇文章的例子：

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text

# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf

# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary

In one of my project's repository:

在我的项目存储库之一中：

* text=auto

*.txt         text eol=lf
*.xml         text eol=lf
*.json        text eol=lf
*.properties  text eol=lf
*.conf        text eol=lf

*.awk  text eol=lf
*.sed  text eol=lf
*.sh   text eol=lf

*.png  binary
*.jpg  binary

*.p12  binary

It's a bit more things to set up, but do it once per project, and any contributor on any OS should have no troubles with line endings when working with this project.

要设置的东西要多一些，但是每个项目都要做一次，并且任何操作系统上的任何贡献者在处理这个项目时都应该没有行尾问题。

回答by Roman Rhrn Nesterov

In vim open the file (e.g.: :e YOURFILEENTER), then

在vim中打开文件（例如：）:e YOURFILEENTER，然后

:set noendofline binary
:wq

回答by Tim Abell

I had this problem too.

我也有这个问题。

SVN doesn't do any line ending conversion, so files are committed with CRLF line endings intact. If you then use git-svn to put the project into git then the CRLF endings persist across into the git repository, which is not the state git expects to find itself in - the default being to only have unix/linux (LF) line endings checked in.

SVN 不进行任何行尾转换，因此文件以完整的 CRLF 行尾提交。如果您随后使用 git-svn 将项目放入 git 中，则 CRLF 结尾会一直存在到 git 存储库中，这不是 git 期望自己处于的状态 - 默认情况下只有 unix/linux (LF) 行结尾入住。

When you then check out the files on windows, the autocrlf conversion leaves the files intact (as they already have the correct endings for the current platform), however the process that decides whether there is a difference with the checked in files performs the reverse conversion beforecomparing, resulting in comparing what it thinks is an LF in the checked out file with an unexpected CRLF in the repository.

然后当您在 Windows 上检出文件时，autocrlf 转换使文件完好无损（因为它们已经具有当前平台的正确结尾），但是决定与检入文件是否存在差异的过程会执行反向转换在比较之前，导致将它认为是检出文件中的 LF 与存储库中的意外 CRLF 进行比较。

As far as I can see your choices are:

据我所知，您的选择是：

1. Re-import your code into a new git repository without using git-svn, this will mean line endings are converted in the intial git commit --all
2. Set autocrlf to false, and ignore the fact that the line endings are not in git's preferred style
3. Check out your files with autocrlf off, fix all the line endings, check everything back in, and turn it back on again.
4. Rewrite your repository's history so that the original commit no longer contains the CRLF that git wasn't expecting. (The usual caveats about history rewriting apply)

1. 在不使用 git-svn 的情况下将您的代码重新导入新的 git 存储库，这意味着行结尾在初始git commit --all 中被转换
2. 将 autocrlf 设置为 false，并忽略行尾不是 git 首选样式的事实
3. 在关闭 autocrlf 的情况下检查您的文件，修复所有行尾，重新检查所有内容，然后再次打开它。
4. 重写存储库的历史记录，以便原始提交不再包含 git 不期望的 CRLF。（关于历史重写的通常警告适用）

---

---

Footnote:if you choose option #2 then my experience is that some of the ancillary tools (rebase, patch etc) do not cope with CRLF files and you will end up sooner or later with files with a mix of CRLF and LF (inconsistent line endings). I know of no way of getting the best of both.

脚注：如果您选择选项 #2，那么我的经验是一些辅助工具（rebase、patch 等）无法处理 CRLF 文件，您迟早会得到混合了 CRLF 和 LF（不一致的行）的文件结局）。我知道没有办法充分利用两者。

回答by basiloungas

Removing the below from the ~/.gitattributes file

从 ~/.gitattributes 文件中删除以下内容

* text=auto

* text=auto

will prevent git from checking line-endings in the first-place.

将阻止 git 首先检查行尾。