J Wyman, thanks for working on this. I ran into this problem as well. I'm not sure if this helps, but when I ran into it, I was diffing a lot of staged changes using the compare with unmodified action in the right click context menu.

Thank you for your feedback! The Visual Studio team has determined that this issue will not be addressed in the upcoming release. We will continue to evaluate it for future releases. This issue is caused by an orphaned .git\index.lock which you'll need to delete. Thank you for helping us build a better Visual Studio!

Retracting previous statement. Completely my error, but I updated the wrong issue. My apologies for getting hopes up or posting misleading information. I still do not have a solid reproduction of this issue (unstage / undo does not work).

We want to provide an update here. As previously noted, this is due to an orphaned git index.lock. We plan to address this in a future update, but in the meantime, the workaround is as J described:
"When this issue happens, please look in the repositories .git/ folder and check for an index.lock file. If one exists, and you're not actively running a Git command, try deleting the file. Git uses this file to indicate to any other Git processes that the repository is locked for editing. Unfortunately, if the editing process crashed or was terminated the index.lock file can get left behind and prevent any other Git process from editing the repository."

Based on this https://stackoverflow.com/questions/14075581/git-undo-all-uncommitted-or-unsaved-changesI did "git checkout ." and "git reset" on the command line at the clone root path, for example C:\Sourcedir\Repos\MyRepo

All pending changes disappeared in VS.

In my situation the repository was just cloned from TFS and immediately after I opened the solution in visual studio there were many pending changes which stage+unstage / undo in VS didn't fix.

Solutions

Another workaround, until I can get the fix (aka solution) into the final product.

When this issue happens, please look in the repositories .git/ folder and check for an index.lock file. If one exists, and you're not actively running a Git command, try deleting the file. Git uses this file to indicate to any other Git processes that the repository is locked for editing. Unfortunately, if the editing process crashed or was terminated the index.lock file can get left behind and prevent any other Git process from editing the repository.

I have no index.lock file in the .git folder but also see this issue. As the OP stated, Sourcetree is successful via their UI as is regular git command "git checkout -- myfilename.ext"The changes list in VS reflects the change as soon as performed outside VS.

This is more of a workaround than a solution. You can always commit the mistake (assuming your entire commit is a mistake), show the history of the branch, right click on the previous commit and choose Reset and Delete Change (--hard)