Git：如何在更改其 EOL 后恢复文件历史记录责备轨道？答案

【问题标题】：Git: How to restore a file history blame track after changed its EOL?Git：如何在更改其 EOL 后恢复文件历史记录责备轨道？
【发布时间】：2021-07-29 20:05:04
【问题描述】：

我们有一些文件最初是在 Windows 下使用 EOL (CRLF) 创建的，而其他文件是在 Linux (LF) 下创建的，有时 IDE（或重新安装后配置错误的 Git）会更改那些 EOL 覆盖并让我们失去整个历史文件（blame 完全没用，只需使用 -w 即可）。

我尝试跟踪文件最后一次正常的时间，在切换 EoL 并替换它之前，但没有工作，从另一个分支检索该文件。由于文件的更改总是很小，因此在多次提交和合并后我没有注意到这个问题，我有一个 6 个月大的分支，原来的 EOL。

如何修复这些文件？

【问题讨论】：

标签： git eol git-blame

【解决方案1】：

你需要用 -w 来责备：

git blame -w some-file

还有其他选项可以控制这一点，-w 表示“不考虑空格/制表符/换行符”。

以防万一，您应该不首先进行这些 EOL 更改。从长远来看，它们是一种痛苦。

自我推销警告：这篇“文章”（因为没有更好的词）谈到了合并时的 EOL 变化。它还指出了解决 EOL 问题的方法……但使用脚本时有一些注意事项……您可能会从中开发一些东西（没有跟踪，没有货币化）。 http://www.ezconflict.com/en/conflictsse16.html#x80-1200003.2

【讨论】：

我知道选项-w，我在帖子中提到过，必须存储库（Assembla，Github）默认不允许使用此选项，也不允许使用它。我正在寻找解决方案。你已经帮助过我一次 stackoverflow.com/questions/64246336/… 但正如你所提到的，它不适用于合并的分支
解决方案？您需要避免更改修订版的 EOL 更改。如果有更改文件 EOL 的 MR/PR，则拒绝它。
刚刚阅读了您的文章，非常棒，感谢您撰写本文。我将停止接受更改 EOL 的 PR！而且我会开始确保当我唠叨团队成员关于他们错误的 EOL 时，我会在分支合并之前这样做，或者如果我一开始错过了就接受它。
您还可以执行一次“规范化/修复所有 EOL”提交，如果您在 git blame 期间遇到过该提交，请跳过它（有一个责备选项）。所以这有很多技巧。

【解决方案2】：

Blame 使用您的文本转换，因此您可以对内容运行任何您想要的预通行证。

echo itssamsfault.c diff=demanglenewlines >>.git/info/attributes
git -c diff.demanglenewlines.textconv="sed 's,\r+$,,'" blame itssamsfault.c

【讨论】：

hmmm...我不知道那个脚本有没有用，现在我有一条消息's,\r+$,,' is not a valid attribute name: .git/info/attributes:1
我认为你一定打错了，'s,\r+$,,' 不应该在 .git/info/attributes 中，它是一个配置值，这里在命令行上提供了责备。这对我有用，当我将 sed 更改为 sed 's,$,hithere,' 时，每行末尾都会显示责备。