无法丢弃GIT中的文件更改 [英] Cant discard file changes in GIT

问题描述

我遇到了问题，我不能放弃对文件的更改.在diff中，它表明所有行均已删除并重新粘贴.但是文件的内容类似于分支中的初始提交. Intellij IDEA显示存储库没有差异.

I faced problem, that I can't discard changes to the file. In diff it showed that all lines was deleted and new pasted. But content of the file similar to the initial commit in branch. Intellij IDEA shows that there are no diff with repository.

我是GIT的新手，请耐心等待)

I am new one to GIT, so please be patient)

推荐答案

关于发生的事情，我最好的猜测是您在Windows计算机上，并且在.gitattributes文件中的某个地方有一条指令告诉git执行行尾归一化(通过* text=auto或类似方法).如果确实如此，那么在签出文件时，其LF将转换为CRLF，而在提交文件时，其CRLF将转换为LF.

My best guess as to what is happening is that you are on a Windows machine, and that somewhere in your .gitattributes file you have a directive that tells git to perform line ending normalizations (via * text=auto or something similar). If this is indeed the case, then when you checkout a file its LFs are converted to CRLFs, and when you commit a file its CRLFs are converted to LFs.

如果确实是这种情况，那么最有可能发生的是所讨论文件的存储库版本中某种程度上包含CRLF.当您签出它们时，工作副本当然也将具有这些CRLF.现在是麻烦所在:在执行git status，git diff等时，git会将repo/index中的内容与工作目录中的实际内容进行比较，而不是将要提交的内容(em)进行比较.行结束标准化后，即用LF替换CRLF.在这种情况下，git看到索引/存储库中的内容具有CRLF，而您将提交的内容仅具有LF，因此存在差异.

If this is indeed the case, then what is most likely happening is that the repository version of the files in question somehow have CRLFs in them. When you check them out, the working copies would of course also have those CRLFs. Now here's the rub: when doing a git status, git diff, etc. git compares what is in the repo/index not to what is actually in your working directory, but to what would be committed after line ending normalization is done, i.e. with the CRLFs replaced by LFs. In this case, git sees that what is in the index/repo has CRLFs, and what you would commit only has LFs, and thus there is a difference.

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

To see if this is the case, run the following commands:

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

第一个命令将显示将要提交的 的哈希值.第二个命令向您显示工作目录中实际存在的哈希值.第三个命令显示索引中的哈希值.如果第一个和第二个哈希不同，并且第二个和第三个哈希相同，那么您几乎肯定处于我所描述的情况.

The first command will show you the hash of what would be committed. The second command shows you the hash of what is actually in your working directory. The third command shows you the hash of what is in the index. If the first and second hashes are different, and the second and third hashes are the same, you are almost definitely in the situation I have described.

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

So the question is, how to get out of it? One simple way is to simply add/commit the "changes". This will have the effect of putting LFs in the repository copy, solving the problem going forward. If everyone using the repository is on Windows, however, there is really no need for the line normalizations anyway. You can disable them by putting * -text in your .gitattributes file (and removing any lines below it that sets the type of a file to text). That's the option I chose when I ran into this problem, as I'm not a fan of my version control system changing the contents of my files.

这篇关于无法丢弃GIT中的文件更改的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！