Git：从源代码控制文件中删除回车
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2466959/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Git: Removing carriage returns from source-controlled files
提问by Blixt
I've got a Git repository that has some files with DOS format (\r\nline endings). I would like to just run the files through dos2unix(which would change all files to UNIX format, with \nline endings), but how badly would this affect history, and is it recommended at all?
我有一个 Git 存储库，其中包含一些 DOS 格式的文件（\r\n行尾）。我只想运行这些文件dos2unix（这会将所有文件更改为 UNIX 格式，并带有\n行尾），但这会对历史影响有多严重，是否完全推荐？
I assume that the standard is to always use UNIX line endings for source-controlled files, and optionally switch to OS-specific line endings locally?
我假设标准是始终将 UNIX 行结尾用于源代码控制的文件，并可选择在本地切换到特定于操作系统的行结尾？
采纳答案by Debilski
The approach you'll have to use depends on how public your repository is.
您必须使用的方法取决于您的存储库的公开程度。
If you don't mind or care about changing all SHAs because you're more or less the only one using it but want to have this issue sorted out for all times, you can run a git filter-branchand apply dos2unixto all files in each commit. (If you're sharing the repository, everyone else needs more or less to completely renew it, so this is potentially dangerous.)
如果您不介意或不关心更改所有 SHA，因为您或多或少是唯一使用它的人，但希望始终解决此问题，则可以运行 agit filter-branch并应用于dos2unix每次提交中的所有文件。（如果您正在共享存储库，其他人或多或少都需要完全更新它，因此这有潜在危险。）
So the better option and also an easier way would be to change it only in the current heads. This means that your past commits still have \r\nendings but unless you're doing much cherry-picking from the past this should not be a problem. The diff tools might complain a bit more often, of course, but normally you'll only diff with commits in the vicinity, so this issue resolves itself as the commits accumulate.
所以更好的选择也是更简单的方法是只在当前的头部改变它。这意味着你过去的提交仍然有\r\n结局，但除非你从过去做很多挑选，否则这应该不是问题。当然，diff 工具可能会更频繁地抱怨，但通常您只会对附近的提交进行 diff，因此这个问题会随着提交的积累而自行解决。
And UNIX line endings are standard, you're correct about that. Best approach is to setup your editor to only write these endings even on windows. Otherwise, there is also a autocrlfsetting which you can use.
UNIX 行结尾是标准的，你是对的。最好的方法是设置你的编辑器，即使在 Windows 上也只写这些结尾。否则，autocrlf您还可以使用一个设置。
Addition to the history rewriting part:
历史改写部分的补充：
Last time I did the same, I used the following command to change all files to unix endings.
上次我也这样做了，我使用以下命令将所有文件更改为 unix 结尾。
#!/bin/bash
all2dos() { find * -exec dos2unix {} \; }
export -f all2dos
git filter-branch -f --tree-filter 'all2dos' --tag-name-filter cat --prune-empty -- --all
回答by pn1 dude
This crlf thing drove us crazy when we converted from svn to git (in a central (bare) like) scm environment. The thing that ultimately got us was we copied the global .gitconfig file to everyone's user root (yep both windows and linux) with the initial one coming from a Windows system and having core.autocrlf=true and core.safecrlf=false which played havoc on the linux users (like bash scripts didn't work and all those awful ^M's). So we initially did a checkout and clone script that did a dos2unix after these commands. Then I ran across the core.autocrlf and core.safecrlf config items and set them based on the O/S:
当我们从 svn 转换到 git（在中央（裸）类似的 scm 环境中）时，这个 crlf 事情让我们发疯了。最终让我们得到的是我们将全局 .gitconfig 文件复制到每个人的用户根目录（是的 Windows 和 linux），最初的文件来自 Windows 系统并具有 core.autocrlf=true 和 core.safecrlf=false ，这造成了严重破坏在 linux 用户上（例如 bash 脚本不起作用以及所有那些糟糕的 ^M）。所以我们最初做了一个 checkout 和 clone 脚本，在这些命令之后做了一个 dos2unix。然后我运行了 core.autocrlf 和 core.safecrlf 配置项并根据 O/S 设置它们：
Windows: core.autocrlf=true and core.safecrlf=false Linux: core.autocrlf=input and core.safecrlf=false
Windows：core.autocrlf=true 和 core.safecrlf=false Linux：core.autocrlf=input 和 core.safecrlf=false
These were set with: ---on Windows---
这些设置为：---在Windows上---
git config --global core.autocrlf true
git config --global core.safecrlf false
---on Linux---
---在Linux上---
git config --global core.autocrlf input
git config --global core.safecrlf false
Then for our Linux developers we setup a little bash script /usr/local/bin/gitfixcrlf:
然后对于我们的 Linux 开发人员，我们设置了一个小 bash 脚本 /usr/local/bin/gitfixcrlf：
#!/bin/sh
# remove local tree
git ls-files -z | xargs -0 rm
# checkout with proper crlf
git checkout .
Which they only had to run on their local sandbox clones once. Any future cloning was done correctly. Any future push pulls now were handled correctly. So, this solved our multiple O/S issues with linefeeds. Also Note that Mac falls in the same config as Linux.
他们只需要在本地沙箱克隆上运行一次。任何未来的克隆都正确完成。现在任何未来的推拉都得到了正确处理。因此，这解决了换行符的多个 O/S 问题。另请注意，Mac 与 Linux 的配置相同。
回答by Cascabel
For the continuing solution, have a look at the core.autocrlf (and core.safecrlf) config parameters.
对于持续的解决方案，请查看 core.autocrlf（和 core.safecrlf）配置参数。
Doing this once to your whole repository will just create one commit that's pretty impossible to merge with (since every line in those files will be modified), but once you get past it, it should be no big deal. (Yes, you could use git filter-branchto make the modification all the way through history, but that's a bit scary.)
对整个存储库执行一次此操作只会创建一个几乎不可能合并的提交（因为这些文件中的每一行都将被修改），但是一旦通过它，应该没什么大不了的。（是的，您可以使用git filter-branch整个历史进行修改，但这有点可怕。）
回答by phyatt
If your list of version controlled files includes binaries, or you can't change history easily... here is a handy dandy one-liner:
如果您的版本控制文件列表包含二进制文件，或者您无法轻松更改历史记录……这是一个方便的单行：
