git工作目录中的变化拒绝被恢复 [英] Changes in git working directory refuse to be reverted

问题描述

我的git工作目录中有五个文件，其中 git status 显示为已修改。当我 git diff 它们时，整个文件显示为已更改。我有 core.autocrlf true 但它似乎没有效果。

真正的问题在我尝试从一位同事那里得到改变。其中一个修改过的文件将被合并覆盖，所以我将其隐藏起来。令我惊讶的是，变化仍在。

pre $ [dev @ carbon：/ var / www / html / ourcustomer] $ git stash
保存的工作目录和索引状态WIP on master：ccb93db合并远程分支'origin / master'
HEAD现在位于ccb93db合并远程分支'origin / master'
[dev @ carbon：/ var / www / html / ourcustomer] $ git status
＃分支主
＃已更改但未更新：
＃（使用git add< file> ...来更新将提交的内容）
＃ （使用git checkout - < file> ...放弃工作目录中的更改）
＃
＃modified：src / ourcustomer / SiteBundle / Resources / public / css / main.css
＃modified：src / ourcustomer / SiteBundle / Resources / public / js / main.js
＃modified：src / ourcustomer / SiteBundle / Resources / public / js / ourcompany-resize.js
＃修改：src / ourcustomer / SiteBundle / Resources / views / Login / languageSelector.html.twig
＃modified：src / ourcustomer / SiteBundle / Resources / views / layout.html.twig
＃
没有变化 添加到提交（使用git add和/或git commit -a）


，我试着 git reset --hard HEAD - 同样的结果。我也尝试过 git checkout - src / ourcustomer / SiteBundle / Resources / public / css / main.css ，但它也没有帮助。

这里可能有什么问题？有什么方法可以解决这个问题吗？或者我应该删除并克隆整个存储库？

解决方案

正在发生的事情是你在Windows机器上，并且在你的 .gitattributes 文件中的某个地方，你有一个指令，告诉git执行行结束标准化（通过 * text = auto 或类似的东西）。如果确实如此，那么当您签出一个文件时，它的LF将被转换为CRLF，并且当您提交一个文件时，它的CRLF将被转换为LF。

如果确实如此，那么最有可能发生的情况是所涉及文件的存储库版本以某种方式具有CRLF。当你检查出来时，工作副本当然也会有这些CRLF。现在来看看这个问题：在执行 git status ， git diff 等时，git会比较回购/索引不是实际在你的工作目录中，而是在完成行结束标准化之后提交什么，即用CR代替CRLF。在这种情况下，git会发现索引/ repo中的内容具有CRLF，而您将仅提交LF，因此存在差异。

若要查看是否属于这种情况，请运行以下命令：

  git hash-object src / ourcustomer / SiteBundle / Resources / public / css / main.css 
 git hash-object --no-filter src / ourcustomer / SiteBundle / Resources / public / css / main.css 
 git ls-files -s src /ourcustomer/SiteBundle/Resources/public/css/main.css 
  

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

所以问题是，如何摆脱它？一个简单的方法是简单地添加/提交更改。这会将LF放入存储库副本中，从而解决未来的问题。但是，如果每个使用存储库的人都在Windows上，那么实际上不需要线路规范化。您可以通过在 .gitattributes 文件中放入 * -text 来禁用它们（并删除它下面的任何行，文件类型为文本）。这是我遇到这个问题时选择的选项，因为我不是我的版本控制系统的粉丝，改变了我的文件内容。

I have five files in my git working directory that git status shows as modified. When I git diff them, the whole file shows as changed. I have core.autocrlf true but it seems to have no effect.

The real problem surfaced when I tried to pull changes from a colleague. One of the "modified" files would have been overwritten by the merge so I stashed them. To my surprise, the changes were still there.

[dev@carbon:/var/www/html/ourcustomer]$ git stash
Saved working directory and index state WIP on master: ccb93db Merge remote branch 'origin/master'
HEAD is now at ccb93db Merge remote branch 'origin/master'
[dev@carbon:/var/www/html/ourcustomer]$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   src/ourcustomer/SiteBundle/Resources/public/css/main.css
#       modified:   src/ourcustomer/SiteBundle/Resources/public/js/main.js
#       modified:   src/ourcustomer/SiteBundle/Resources/public/js/ourcompany-resize.js
#       modified:   src/ourcustomer/SiteBundle/Resources/views/Login/languageSelector.html.twig
#       modified:   src/ourcustomer/SiteBundle/Resources/views/layout.html.twig
#
no changes added to commit (use "git add" and/or "git commit -a")

After this, I tried git reset --hard HEAD - same result. I also tried to git checkout -- src/ourcustomer/SiteBundle/Resources/public/css/main.css, but it didn't help either.

What could be wrong here? Is there some way to fix this or should I just delete and clone the whole repository again?

解决方案

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.

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 src/ourcustomer/SiteBundle/Resources/public/css/main.css 
git hash-object --no-filter src/ourcustomer/SiteBundle/Resources/public/css/main.css 
git ls-files -s src/ourcustomer/SiteBundle/Resources/public/css/main.css 

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.

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屋！