【问题标题】:Cant discard file changes in GIT无法丢弃 GIT 中的文件更改
【发布时间】:2014-11-12 05:18:02
【问题描述】:

我遇到了问题,我无法放弃对文件的更改。在 diff 中,它显示所有行都已删除并新粘贴。但是文件的内容类似于分支中的初始提交。 Intellij IDEA 显示与存储库没有差异。

我是GIT新手,请耐心等待)

【问题讨论】:

  • 如果你运行git checkout <file>然后再检查git diff,结果是一样的吗?另外,当您查看 diff 时,内容看起来是否相同(可能是行尾或编码已更改)?
  • Diff 显示所有原始行都已删除,并替换为新行(它们具有相同的内容)。行尾也一样。
  • Git 并不是这样工作的。它大多不知道文件,它只关心文件内容。
  • 所以你丢弃了文件但git diff 仍然显示它是一样的?你是windows系统吗?如果“filemode”设置为真,Git 可能认为文件已更改,因为它已成为可执行文件,因为在 windows 系统上签出。
  • 是的,丢弃后差异显示相同。是的,我在 Windows 上。将“filemode”设置为 false - 没有帮助。

标签: git


【解决方案1】:

我对正在发生的事情的最佳猜测是你在一台 Windows 机器上,并且在你的 .gitattributes 文件中的某个地方你有一个指令告诉 git 执行行尾规范化(通过 * text=auto 或类似的东西) .如果确实如此,那么当您签出文件时,其 LF 将转换为 CRLF,而当您提交文件时,其 CRLF 将转换为 LF。

如果情况确实如此,那么最有可能发生的是相关文件的存储库版本以某种方式在其中包含 CRLF。当您检查它们时,工作副本当然也有那些 CRLF。现在问题来了:在执行git statusgit diff 等操作时,git 将 repo/index 中的内容与您的工作目录中的实际内容进行比较,而不是与 提交的内容进行比较行结束规范化完成后,即用 LF 替换 CRLF。在这种情况下,git 会看到 index/repo 中的内容具有 CRLF,而您提交的内容只有 LF,因此存在差异。

要查看是否是这种情况,请运行以下命令:

git hash-object path/to/filename
git hash-object --no-filter path/to/filename
git ls-files -s path/to/filename

第一个命令将向您显示提交的内容的哈希值。第二个命令向您显示工作目录中实际内容的哈希值。第三个命令显示索引中内容的哈希值。如果第一个和第二个哈希值不同,而第二个和第三个哈希值相同,那么您几乎肯定是我描述的情况。

所以问题是,如何摆脱它?一种简单的方法是简单地添加/提交“更改”。这将具有将 LF 放入存储库副本中的效果,从而解决了未来的问题。但是,如果使用存储库的每个人都在 Windows 上,那么无论如何都不需要行规范化。您可以通过将 * -text 放入您的 .gitattributes 文件中来禁用它们(并删除其下方将文件类型设置为文本的任何行)。这是我遇到此问题时选择的选项,因为我不喜欢我的版本控制系统更改我的文件内容。

【讨论】:

    猜你喜欢
    • 2019-01-14
    • 2010-12-07
    • 2012-10-27
    • 2015-03-08
    • 2020-06-01
    • 1970-01-01
    • 2014-05-28
    • 1970-01-01
    • 2014-01-24
    相关资源
    最近更新 更多