git diff broken in 1.86

[af4jm]

Type: Bug

Since 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 (05047486b6df5eb8d44b2ecd70ea3bdf775fd937, 2024-01-31T10:28:19.990Z) OS version: Windows_NT x64 10.0.22631 Modes:

System Info

|Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz (8 x 1800)| |GPU Status|2d_canvas: enabled
canvas_oop_rasterization: enabled_on
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_graphite: disabled_off
video_decode: enabled
video_encode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: enabled| |Load (avg)|undefined| |Memory (System)|31.88GB (16.13GB free)| |Process Argv|--file-uri file:///c%3A/src/AF4JM.code-workspace --crash-reporter-id 06338080-eec2-498d-98e0-cf3111dc1cde| |Screen Reader|no| |VM|0%|

Extensions (55)

Extension|Author (truncated)|Version ---|---|--- vscode-icalendar|af4|1.0.1 vscode-m3u|af4|1.0.0 vscode-caniuse|aga|0.5.0 case-change|Aka|1.0.2 rtf|ale|2.7.0 spellright|ban|3.0.122 markdown-checkbox|bie|0.4.0 markdown-emoji|bie|0.3.0 markdown-mermaid|bie|1.21.0 markdown-yaml-preamble|bie|0.1.0 vscode-tldr|bmu|1.0.0 gitignore|cod|0.9.0 vscode-markdownlint|Dav|0.54.0 vscode-eslint|dba|2.4.4 rushcore|Dev|1.0.2 rushnav|Dev|1.0.2 githistory|don|0.6.20 xml|Dot|2.5.1 escaping-characters|drp|1.0.0 EditorConfig|Edi|0.16.4 vscode-macros|EXC|1.4.1 git-project-manager|fel|1.8.2 url-encode|fle|1.1.0 shell-format|fox|7.2.5 matlab|Gim|3.0.2 vscode-pull-request-github|Git|0.80.0 gc-excelviewer|Gra|4.2.58 vscode-markdown-footnote|hou|1.0.0 vscode-favorites|how|1.11.0 rest-client|hum|0.25.1 path-autocomplete|ion|1.25.0 mediawiki|jak|2.1.0 anki|jas|1.3.1 markdown-katex|jef|0.1.4 vscode-peacock|joh|4.2.2 gpg|jva|1.1.1 zotero|mbl|0.1.11 markdown-shortcuts|mdi|0.12.0 debugpy|ms-|2024.0.0 jupyter-keymap|ms-|1.1.2 jupyter-renderers|ms-|1.0.17 vscode-jupyter-cell-tags|ms-|0.1.8 vscode-jupyter-slideshow|ms-|0.1.5 azure-account|ms-|0.11.6 azurecli|ms-|0.6.0 hexeditor|ms-|1.9.13 live-server|ms-|0.4.13 vscode-yaml|red|1.14.0 vscode-zipexplorer|sle|0.3.1 pdf|tom|1.2.2 intellicode-api-usage-examples|Vis|0.2.8 vscodeintellicode|Vis|1.2.30 vscode-icons|vsc|12.7.0 org-mode|vsc|1.0.0 JavaScriptSnippets|xab|1.8.0

A/B Experiments

``` vsliv368cf:30146710 vspor879:30202332 vspor708:30202333 vspor363:30204092 vscod805:30301674 binariesv615:30325510 vsaa593:30376534 py29gd2263:30899288 c4g48928:30535728 azure-dev_surveyone:30548225 962ge761:30951796 pythongtdpath:30769146 welcomedialog:30910333 pythonidxpt:30866567 pythonnoceb:30805159 asynctok:30898717 pythontestfixt:30902429 pythonregdiag2:30936856 pyreplss1:30897532 pythonmypyd1:30879173 pythoncet0:30885854 pythontbext0:30879054 accentitlementst:30887150 dsvsc016:30899300 dsvsc017:30899301 dsvsc018:30899302 dsvsc019b:30953937 3ef8e399:30949928 ```

[gjsjohnmurray]

Please use the Start Extension Bisect command to investigate whether the problem is being caused by one of your extensions.

[af4jm]

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

[af4jm]

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 new release label, unless there's been another Release since 1.86, and the Releases page still shows that as the newest version

[SamHasler]

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)/¯

[Timmmm]

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:

    "git.openDiffOnClick": false,

Do you guys have that set?

[af4jm]

yes, I do have that setting... and if I comment it out, I see the correct behavior

[lszomoru]

Sorry for not getting back to you on this. Could any of you experiencing this issue provide a screen recording illustrating the issue (https://gifcap.dev)? Thank you very much in advance!

[Timmmm]

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.

[lszomoru]

Are you able to reproduce the issue if you disable the git.optimisticUpdate setting? Thanks!

[Timmmm]

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.

[af4jm]

@lszomoru if I add "git.openDiffOnClick": false 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

[af4jm]

video was way over GitHub's 10MB limit... so dropped it in my OneDrive & tried to include it as an image...

https://1drv.ms/i/s!Auy35hyaQsjmnpB70oGx2DvOlOjaXg?e=YLgT5J

[lszomoru]

@af4jm, could you please re-upload the recording as it looks like it is not available at the link any more. Thanks!

[af4jm]

@af4jm, 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

[lszomoru]

@af4jm, any news on the recording? Thank you!

[af4jm]

with "git.openDiffOnClick": false in settings (without it I see expected behavior)

[lszomoru]

@af4jm, 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.

[vs-code-engineering[bot]]

This bug has been fixed in the latest release of VS Code Insiders!

@af4jm, you can help us out by commenting /verified if things are now working as expected.

If things still don't seem right, please ensure you're on version 4c94dbdf0c1ce60b7c63ad74dc8e6740b0f2de04 of Insiders (today's or later - you can use Help: About in the command palette to check), and leave a comment letting us know what isn't working as expected.

Happy Coding!

[vs-code-engineering[bot]]

Friendly ping! Looks like this issue requires some further steps to be verified. Please provide us with the steps necessary to verify this issue.

[lszomoru]

Verification steps:

1. Launch VS Code Insiders
2. Set git.openDiffOnClick to false
3. Open a file, modify it and save it
4. Open the Source Control view and click on "Open Changes" action
   • Confirm that the diff is rendered correctly
5. Click on the "Stage Changes" action
6. Click on "Open Changes" action
   • Confirm that the diff is rendered correctly