git diff broken in 1.86
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 |
| 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
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 new release 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:
"git.openDiffOnClick": false,
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 (https://gifcap.dev)? 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 git.optimisticUpdate 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.
@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
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
@af4jm, could you please re-upload the recording as it looks like it is not available at the link any more. Thanks!
@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
@af4jm, any news on the recording? Thank you!
with "git.openDiffOnClick": false in settings (without it I see expected behavior)
@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.
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!
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:
- Launch VS Code Insiders
- Set
git.openDiffOnClicktofalse - Open a file, modify it and save it
- Open the Source Control view and click on "Open Changes" action
- Confirm that the diff is rendered correctly
- Click on the "Stage Changes" action
- Click on "Open Changes" action
- Confirm that the diff is rendered correctly