Change:
return -1; } <ins> if (result !== 0) { return result; } </ins> if (a.multiFileDiffEditorModifiedUri && b.multiFileDiffEditorModifiedUri) { result = comparePaths(a.multiFileDiffEditorModifiedUri.fsPath, b.multiFileDiffEditorModifiedUri.fsPath, true); } else if (a.multiFileDiffEditorModifiedUri) {

Discussion:
Type: <bBug</bSince updating to 1.86, when I open a git diff in VSCode, I see the latest version of the file on both sides, showing no differences (except that word wrap is off on the left & on on the right... it's on everywhere else)... if I stage a file, open the diff, then unstage the file, then I see the correct diff like I've always seen before likely related: the new +- buttons next to Changes & Staged Changes show the same behavior (although while playing with it, I did have one time where I saw the correct diff on the first file) at one point I restarted VSCode, which seemed to resolve the issue, but it was only temporary. once I started editing files again the issue returned not sure if it's relevant or not, but... in all cases, the changes were saved to disk... the git change indicators in the left gutter of open files are not affected by this issue, they continue to work as the always have, showing up as I edit, clearing when I stage the change VS Code version: Code 1.86.0 (, 2024-01-31T10:28:19.990Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (55)</summaryExtensionVersion ------ vscode-icalendar1.0.1 vscode-m3u1.0.0 vscode-caniuse0.5.0 case-change1.0.2 rtf2.7.0 spellright3.0.122 markdown-checkbox0.4.0 markdown-emoji0.3.0 markdown-mermaid1.21.0 markdown-yaml-preamble0.1.0 vscode-tldr1.0.0 gitignore0.9.0 vscode-markdownlint0.54.0 vscode-eslint2.4.4 rushcore1.0.2 rushnav1.0.2 githistory0.6.20 xml2.5.1 escaping-characters1.0.0 EditorConfig0.16.4 vscode-macros1.4.1 git-project-manager1.8.2 url-encode1.1.0 shell-format7.2.5 matlab3.0.2 vscode-pull-request-github0.80.0 gc-excelviewer4.2.

58 vscode-markdown-footnote1.0.0 vscode-favorites1.11.0 rest-client0.25.1 path-autocomplete1.25.0 mediawiki2.1.0 anki1.3.1 markdown-katex0.1.4 vscode-peacock4.2.2 gpg1.1.1 zotero0.1.11 markdown-shortcuts0.12.0 debugpy2024.0.0 jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 azure-account0.11.6 azurecli0.6.0 hexeditor1.9.13 live-server0.4.13 vscode-yaml1.14.0 vscode-zipexplorer0.3.1 pdf1.2.2 intellicode-api-usage-examples0.2.8 vscodeintellicode1.2.30 vscode-icons12.7.0 org-mode1.0.0 JavaScriptSnippets1.8.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Please use the Start Extension Bisect command to investigate whether the problem is being caused by one of your extensions.
I can duplicate this in Insiders with no extensions loaded (... however, that opening & closing revealed more details I didn't realize previously... I only see the buggy behavior with changes made in this session... if I close & reopen VSCode, changes that were staged before VSCode opened render correctly... new changes stop rendering when they're staged (and when I say "stop rendering" I mean no red & green highlights, because both sides of the diff tab contain the new code) & start rendering again when the app is restarted (or I switch between Release & Insiders) side notes: I'm no longer seeing the no word wrap on the left in VSCode (& I never saw it in Insiders), so not sure what was up with that... I know that there are often visual artifacts in one side of the diff editor (e.g. valid relative paths get yellow squiggles on one side but not the other), so guess I'll put this one in that category... who cares?

I'll see that in the main editor, I just want the diff in the diff viewer I forgot to try Insiders before I submitted because it was so obvious that only 1 thing changed, but I'll try to remember that just to make sure it hasn't been fixed already... but, I don't appreciate being asked to go on a wild goose chase bisecting extensions
one more thing I just noticed... prior to 1.86, if I stages a file, then made additional changes, so that the file is now in the Source Control panel twice... the 2 diff buttons would open 2 separate diffs, one with the staged changes & 1 with unstaged... now I get only one (with the unstaged changes) also, it makes no sense that the bot removed the label, unless there's been another Release since 1.86, and the Releases page still shows that as the newest version
I've had this issue since February too. Strangely enough, I started an Extension Bisect, stopped straight away (intending to restart) and now I don't have the issue. ¯(°_o)/¯
I'm hitting this too on two completely different machines (Windows and Linux). The issue is if you click the diff button on a staged file just after staging it, for some reason it opens the working tree diff (which has no differences). If you reload the window so it starts with the file already staged then the button correctly opens the index diff. I reproduced this with no extensions enabled. I think the reason this enormous bug has gone unnoticed for so long (I only just looked into it because I assumed that surely they would fix something as broken as this...), is that it only happens if you have this setting: Do you guys have that set?
yes, I do have that setting... and if I comment it out, I see the correct behavior
Sorry for not getting back to you on this. Could any of you experiencing this issue provide a screen recording illustrating the issue ()? Thank you very much in advance!
Ugh I can't seem to reproduce it at the moment - sometimes it does work, but I haven't found the exact pattern.

So you'll have to use your imagination, but basically you click the diff button for a file (two circles connected by arrows) and it opens a diff view but there are no differences between the files on the left and right of the view. Next time it happens I'll try to record it.
Are you able to reproduce the issue if you disable the setting? Thanks!
Didn't seem to make any difference - I still can't reproduce it, sorry. What does that setting actually do? It doesn't seem to make any difference to behaviour and I don't understand the description: ! The Source Control view still automatically updates even if I have that off.
if I add to my settings I can repro, without it I can't repro... just recorded with gitcap, waiting for it to render so I can get a link
video was way over GitHub's 10MB limit... so dropped it in my OneDrive & tried to include it as an image... !Auy35hyaQsjmnpB70oGx2DvOlOjaXg?e=YLgT5J!
could you please re-upload the recording as it looks like it is not available at the link any more. Thanks!
i will try tonight... on vacay this week, so might need to wait until I'm back on the work PC Monday
any news on the recording? Thank you!
with in settings (without it I see expected behavior) !
thanks again! I have a fix but it will not make the cut for the August 2024 release so it will be in the September 2024 release.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Friendly ping! Looks like this issue requires some further steps to be verified. Please provide us with the steps necessary to verify this issue.

Verification steps: VS Code Insiders to a file, modify it and save it the Source Control view and click on "Open Changes" action Confirm that the diff is rendered correctly on the "Stage Changes" action on "Open Changes" action Confirm that the diff is rendered correctly