git - 带有 Git 的 Visual Studio 2019 - "Undo Changes"并不总是有效

Question

有时在 Visual Studio 2019 中，使用 Git 存储库时，右键单击并选择“团队资源管理器”中的“撤消更改”无法按预期工作。虽然更改确实已撤消，但文件图标仍保留在“更改”标题下。

即使它确实消失了，通常如果我然后运行 ​​git status从控制台，文件名将显示在控制台下 changes not staged for commit .

我可以通过运行 git reset --hard 轻松解决这个问题.即便如此，这也是一种烦恼。知道在 VS 引擎盖下发生了什么导致它以这种方式(错误)运行吗？

Answer 1

根据您的描述(撤消不会更新文件状态，git reset --hard 是一种解决方法)，这听起来像以下问题:
https://developercommunity2.visualstudio.com/t/Undo-changes-with-new-git-experience-pre/1170228
根本原因似乎与行尾有关:
微软:

So our suspicion is that maybe dotnet format rewrote the line endings (and only the line-endings), so now git status reports that there are changed files. However, if you try to actually checkout-index, git will not actually mutate anything. However, git status believes there are changes, because the stat-block is leading it to believe there has been a change (since there has been a change). One way to verify this is to, from the command line, or visual studio. Stage everything (git add *) (you can do this from visual studio by right click > stage) git status (or, if in Visual Studio, it will refresh status automatically) If the files disappear from view, then there's a line-ending issue, and git has suddenly realized that they're actually the same file.

记者:

Yes! Staging everything made all of the files disappear :-)

微软:

Cool! So here’s what we know! For EOL-only changes, SHA changes don’t change. Git apparently stores these internally as LF-only Neither checkout nor checkout-index will overwrite the file on disk ​Basically, since git is our source of truth here, we get misleading information. However, I think git maybe made the right decision here in regards to performance. That being said, this is super confusing from a UX perspective, so we’ll be evaluating this. We’re evaluating how to improve this UX.

该问题仍然存在，但似乎已经确定了根本原因。目前，只有解决方法。