【问题标题】:accidentally changed line ending in git, now can't change back because it says nothing changed意外更改了以 git 结尾的行,现在无法更改回来,因为它说没有任何改变
【发布时间】:2019-08-05 01:08:27
【问题描述】:

几天前,我不小心更改了某个文件的行尾,并提交了更改。 (以前是 CRLF,现在是错误的 LF。)我仍然不知道这是我的编辑器太聪明了,还是 git 太聪明了。 (实际上我怀疑它是 git,根据我试图撤消它的经验。)不管怎样,它已经完成了,我想修复它。我想我可以在我的编辑器中更改行尾,然后只更改行尾进行提交。 Git 拒绝了,声称我没有改变任何东西。所以我也添加了一个虚拟更改,但它随后提交了虚拟更改,但也改变了行尾,所以它们仍然是 LF。可能相关的 git 设置:

C:\Users\ZKZ4PL2\eqs\hot-connect>git config core.eol

C:\Users\ZKZ4PL2\eqs\hot-connect>git config core.autocrlf
input

有什么想法吗?

【问题讨论】:

  • 可能,但不明显。现在最困扰我的是git没有按照我的预期做,这意味着我比我想象的更困惑。由于 autocrlf 设置为 input 然后根据 git 文档“此变量可以设置为 input,在这种情况下不执行输出转换”。那到底是怎么回事?
  • 最好(我的意见!)将 autocrlf=false safecrlf=true 和所有相关的文本文件(例如 *.c)明确地保存在 gitattributes 中。 See虽然一旦你有一个搞砸的回购它更麻烦
  • git 开发者自己 discussing autocrlf 坏了。
  • @MarkVY 还有these commands搞乱后清理

标签: git line-endings


【解决方案1】:

首先,将core.atocrlf 设置为false,以避免Git 进行任何自动eol 转换。

 git config --global core.autocrlf false

其次,检查任何 .gitattributes 文件,以获取其中的 core.eol 指令。

如果您没有,则应在 git add 上选择在编辑器中更改 EOL。

【讨论】:

  • 文档甚至没有提到“false”是一个有效的设置。叹息。
  • @MarkVY 我明白了。在过去的十年里,我一直在提倡/提到“错误”的价值:stackoverflow.com/…。 2009 年 8 月:stackoverflow.com/a/1250133/6309
  • 十年!我想知道如果文档提到这个选项,有多少会被阻止......
【解决方案2】:

Git 看不到任何更改的原因是它在将文件与之前的版本进行比较之前应用了 autocrlf 转换。

行尾管理的最佳策略是禁用 autocrlf 和好友并手动管理您的文件,除非您有非常具体的要求,特别是如果您有需要在 CRLF 中的文件,因为 Git 没有选项'commit files as CRLF', only 'check out files in CRLF'.在几种情况下,Git 可能会感到困惑或导致意外结果(例如,直接从 GitHub 下载文件等会将其下载为 LF,提交文件后更改设置会导致无法提交的更改等)。

autocrlf input 表示 Git 将在提交时将 CRLF 转换为 LF,这是相当具有误导性的(在这种情况下,将其称为 autolf 更合适)。

【讨论】:

  • 文档没有提到这个!至少不在 core.autocrlf 下。
猜你喜欢
  • 2018-01-27
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-12-29
  • 1970-01-01
  • 2020-06-18
  • 1970-01-01
相关资源
最近更新 更多