Menu
For some reason, my VS will not remove the files from changes view after "undo changes" :
The actual changes are gone when I view a diff, but I want the files not to show. I would like to know a permanent solution to this. I already know I can do a stash or similar outside of VS to hide the files from showing.
I have found a work-around. When I undo, then with the remaining files select stage, they disappear!
266
In Visual Studio, LLBLGen Pro uses the global undo / redo shortcuts for undo/redo: Ctrl-Z for undo and Ctrl-Y for redo. The undo-redo for the text editor switches to Ctrl-Shift-Z for undo and Ctrl-Shift-Y for redo in this case.
From the Visual Studio's Edit menu. Clicking the undo and redo icons on the toolbar. Pressing CTRL+Z for undo and CTRL+Y for redo.
The easiest way to undo the last Git commit is to execute the “git reset” command with the “–soft” option that will preserve changes done to your files. You have to specify the commit to undo which is “HEAD~1” in this case. The last commit will be removed from your Git history.
When undoing changes in Git, first decide what type of changes you are looking to undo. These changes fall into three categories: Discard uncommitted changes to a file, bringing the file back to the version in the last commit.
If your change is staged, remove it from the Staged Changes section by right-clicking and selecting Unstage. Right-click that file and select Undo Changes. You can use the checkout command and give it the filename (s) to change. Use wildcards for undoing changes to multiple files.
Discarding uncommitted changes There could be a set of changed files, which you don't want to commit and want to undo the changes that you have already performed. Select those files/folders and right click on them to open the Git context menu, where you can click Undo Changes... to discard them. The files will be reset to the unmodified stage:
Well the best answer I have found is to open a command prompt and navigating to the directory that contains the file that needs to be undone and then run the following command. In this example the changes to gulpfile.babel.js will be undone. This will work for both added and changed files.
Based on your description (undo does not change file list, staging forces an update), this sounds like the following issue related to Visual Studio 2015 and 2017:
https://developercommunity2.visualstudio.com/t/shGitsh---shUndosh-changes-doe/681074?space=8&q=git+undo+2015
According to Microsoft, Visual Studio 2019 is also affected. The problem is now being tracked in this 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 formatrewrote the line endings (and only the line-endings), so nowgit statusreports 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.
182
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
