Visual Studio 2019 with Git - "Undo Changes" doesn't always work

Question

Sometimes in Visual Studio 2019, when working with a Git repo, right-clicking and selecting Undo Changes in Team Explorer doesn't work as expected. While the changes are indeed undone, the file icon still remains under the Changes heading.

Even if it does disappear, oftentimes if I then run git status from the console, the filename will show in the console under changes not staged for commit.

I can fix this easily enough by running git reset --hard. Even so, it's an annoyance. Any idea what's going on under the hood of VS that causes it to (mal)function this way?

Answer 1

Based on your description (undo does not update file status, git reset --hard is a workaround), this sounds like the following issue:

https://developercommunity2.visualstudio.com/t/Undo-changes-with-new-git-experience-pre/1170228

The root cause seems to be related to line endings:

Microsoft:

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.

Reporter:

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

Microsoft:

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.

The issue is still open but it seems that the root caused was identified. For now, there's only the workaround.