在 git repo 和工作副本中强制执行 LF eol [英] Force LF eol in git repo and working copy

问题描述

我在 github 上托管了一个 git 存储库.许多文件最初是在 Windows 上开发的，我不太注意行尾.当我执行初始提交时，我也没有任何 git 配置来强制执行正确的行尾.结果是我的 github 存储库中有许多文件以 CRLF 行结尾.

I have a git repository hosted on github. Many of the files were initially developed on Windows, and I wasn't too careful about line endings. When I performed the initial commit, I also didn't have any git configuration in place to enforce correct line endings. The upshot is that I have a number of files with CRLF line endings in my github repository.

我现在正在 Linux 上进行部分开发，我想清理行尾.如何确保文件在 github 上使用 LF 正确存储，并且在我的工作副本中有 LF?

I'm now developing partially on Linux, and I'd like to clean up the line endings. How can I ensure the files are stored correctly with LF on github, and have LF in my working copy?

我已经建立了一个包含 text eol=LF 的 .gitattributes 文件；那是对的吗?提交并推送后，我是否可以仅 rm 我的本地存储库并从 github 重新克隆以获得所需的效果?

I've set up a .gitattributes file containing text eol=LF; is that correct? With that committed and pushed, can I just rm my local repo and re-clone from github to get the desired effect?

推荐答案

如果没有关于您的存储库中有哪些文件(纯源代码、图像、可执行文件...)的一些信息，则很难回答问题:)

Without a bit of information about what files are in your repository (pure source code, images, executables, ...), it's a bit hard to answer the question :)

除此之外，我会认为您愿意将 LF 默认为工作目录中的行尾，因为无论您在做什么，您都愿意确保文本文件在 .git 存储库中具有 LF 行尾Windows 或 Linux.确实比抱歉更安全......

Beside this, I'll consider that you're willing to default to LF as line endings in your working directory because you're willing to make sure that text files have LF line endings in your .git repository wether you work on Windows or Linux. Indeed better safe than sorry....

但是，还有一个更好的选择:受益于 Linux 工作目录中的 LF 行结尾、Windows 工作目录中的 CRLF 行结尾和存储库中的 LF 行结尾.

However, there's a better alternative: Benefit from LF line endings in your Linux workdir, CRLF line endings in your Windows workdir AND LF line endings in your repository.

当您部分工作在 Linux 和 Windows 上时，请确保将 core.eol 设置为 native 并设置 core.autocrlf到 true.

As you're partially working on Linux and Windows, make sure core.eol is set to native and core.autocrlf is set to true.

然后，将 .gitattributes 文件的内容替换为以下内容

Then, replace the content of your .gitattributes file with the following

* text=auto

这将使 Git 在提交和检出时为您处理自动换行符.二进制文件不会被更改，被检测为文本文件的文件将看到行尾动态转换.

This will let Git handle the automagic line endings conversion for you, on commits and checkouts. Binary files won't be altered, files detected as being text files will see the line endings converted on the fly.

但是，当您知道存储库的内容时，您可以帮助 Git 并帮助他从二进制文件中检测文本文件.

However, as you know the content of your repository, you may give Git a hand and help him detect text files from binary files.

假设您从事基于 C 的图像处理项目，请将 .gitattributes 文件的内容替换为以下内容

Provided you work on a C based image processing project, replace the content of your .gitattributes file with the following

* text=auto
*.txt text
*.c text
*.h text
*.jpg binary

这将确保扩展名为 c、h 或 txt 的文件将与 LF 行结尾一起存储在您的存储库中，并且将在工作目录中具有本机行结尾.Jpeg 文件不会被触及.所有其他人都将受益于与上述相同的自动过滤.

This will make sure files which extension is c, h, or txt will be stored with LF line endings in your repo and will have native line endings in the working directory. Jpeg files won't be touched. All of the others will be benefit from the same automagic filtering as seen above.

为了更深入地了解这一切的内部细节，我建议您深入阅读这篇非常好的帖子 注意你的行尾"，来自 Githubber 的 Tim Clem.

In order to get a get a deeper understanding of the inner details of all this, I'd suggest you to dive into this very good post "Mind the end of your line" from Tim Clem, a Githubber.

作为现实世界的示例，您还可以查看此提交，其中演示了对 .gitattributes 文件所做的更改.

As a real world example, you can also peek at this commit where those changes to a .gitattributes file are demonstrated.

考虑以下评论更新答案

我其实不想在我的 Windows 目录中使用 CRLF，因为我的 Linux 环境实际上是一个共享 Windows 目录的 VirtualBox

有道理.感谢您的澄清.在这个特定的上下文中，.gitattributes 文件本身是不够的.

Makes sense. Thanks for the clarification. In this specific context, the .gitattributes file by itself won't be enough.

对您的存储库运行以下命令

Run the following commands against your repository

$ git config core.eol lf
$ git config core.autocrlf input

由于您的存储库在 Linux 和 Windows 环境之间共享，因此这将更新两个环境的本地配置文件.core.eol 将确保文本文件在结帐时带有 LF 行结尾.core.autocrlf 将确保文本文件中的潜在 CRLF(例如由复制/粘贴操作产生)将在您的存储库中转换为 LF.

As your repository is shared between your Linux and Windows environment, this will update the local config file for both environment. core.eol will make sure text files bear LF line endings on checkouts. core.autocrlf will ensure potential CRLF in text files (resulting from a copy/paste operation for instance) will be converted to LF in your repository.

或者，您可以通过创建包含类似于以下内容的 .gitattributes 文件来帮助 Git 区分文本文件:

Optionally, you can help Git distinguish what is a text file by creating a .gitattributes file containing something similar to the following:

# Autodetect text files
* text=auto

# ...Unless the name matches the following
# overriding patterns

# Definitively text files 
*.txt text
*.c text
*.h text

# Ensure those won't be messed up with
*.jpg binary
*.data binary

如果您决定创建一个 .gitattributes 文件，请提交.

If you decided to create a .gitattributes file, commit it.

最后确保git status提到nothing to commit (working directory clean)"，然后执行以下操作

Lastly, ensure git status mentions "nothing to commit (working directory clean)", then perform the following operation

$ git checkout-index --force --all

这将在您的工作目录中重新创建您的文件，考虑到您的配置更改和 .gitattributes 文件并替换文本文件中任何可能被忽视的 CRLF.

This will recreate your files in your working directory, taking into account your config changes and the .gitattributes file and replacing any potential overlooked CRLF in your text files.

一旦完成，您工作目录中的每个文本文件都将带有 LF 行结尾，并且 git status 仍应将工作目录视为干净的.

Once this is done, every text file in your working directory WILL bear LF line endings and git status should still consider the workdir as clean.

这篇关于在 git repo 和工作副本中强制执行 LF eol的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！