Stage Selected Ranges broken again?

jhillert-dmg commented 2 years ago

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: 1.66.2
OS Version: 11.6 (Big Sur)

Steps to Reproduce:

Make some changes in a file at two different places ("1st changes" and "2nd changes")
Open Source Control Sidebar and select file you just changed to see the diffs for 1st & 2nd changes in the editor.
Select the red and green diff of 1st changes, right click the selection, and choose "Stage selected ranges". RESULT: As expected, the diff of 1st changes will disappear from the editor, the current file will appear under Staged Changes in the sidebar, and the diff of 1st changes will be visible in "Staged Changes" editor.
Go back to the "Changes" editor and repeat step 3 for 2nd changes. EXPECTED RESULT: The same thing should happen for 2nd changes. ACTUAL RESULT: The same thing does happen for 2nd changes, but 1st changes are reverted and move from Stage Changes to Changes (i.e., 2nd changes are staged, 1st changes are unstaged.).

darkvertex commented 2 years ago

Just chiming in to say I'm having extremely erratic "selected ranges" staging behaviour as well. Usually it works great.

Version: 1.66.2 (user setup)
Commit: dfd34e8260c270da74b5c2d86d61aee4b6d56977
Date: 2022-04-11T07:46:01.075Z
Electron: 17.2.0
Chromium: 98.0.4758.109
Node.js: 16.13.0
V8: 9.8.177.11-electron.0
OS: Windows_NT x64 10.0.19044

DevilXD commented 2 years ago

I am experiencing the same issue, although I usually use the green (addition) and blue (change) colored ribbon-thingies (and red triangles for deletion) that appear on the left side of the code after changes. Clicking on them lets me interactively stage a single change from a file, but sometimes trying to stage more than one change, causes the previously staged changes to unstage. It's really annoying. I thought it could be a GitLens issue (since I also use it as well), but I've been told this feature comes from VSCode itself.

guanzo commented 2 years ago

I'm seeing this issue in WSL mode.

eldar commented 1 year ago

This one is still broken. Here is a screen recording demonstrating the bug: https://imgur.com/a/ma7I0pj

Also no visual feedback is provided when staging individual changes.

bandtank commented 1 year ago

If you navigate away from the file after staging a selected range, it works. The issue needs to be fixed, but this crappy workaround helps in the interim.

phoenixeliot commented 1 year ago

I don't know if this is related yet but I'm finding that "stage selected changes" is ignoring deletions, only staging additions

chiholai-sanasofthk commented 1 year ago

bump, still an issue in 1.77

freerror commented 1 year ago

bump, still an issue in 1.77

It should be noted that in the working tree split view it works only on the right pane or end result side. For some reason I was trying to stage my changes by selecting the change on original side which doesn't work. Maybe this will help anyone who googled this issue.

Pulseczar1 commented 1 year ago

This is also happening to me in version 1.77.3, Linux x64. I'm not attempting to stage changes on the left pane -- only on the right pane. It was such a nice feature in the previous version I was using, where I never had any issues with the feature. Some notes about it:

To get VS Code to "accept" the staging (react at all and no longer show the change), you have to switch to another tab and back. I like to switch to the Staged Changes version of the file and then back to the Changes version, in the Source Control file selector. Doing that gets it to behave similar to the way it did when there wasn't a problem. EDIT: I found that just alt-tabbing to any other window and back to VS Code makes the Working Tree tab update to show the staged change properly, the way it used to work, without having to alt-tab or anything else.
However, if you stage multiple selections, only the last one staged actually gets staged. So, you have to get it to update after every staging, in order to get it to accept every staging.
Another alternative is to use the line staging functionality in the "main" file tab, available in the file Explorer. Click the colored lines that show up to the left of the changed lines and to the right of the line numbers (if those are turned on). Use the plus sign button to stage the change in the line. That functionality still works. (But I prefer the side-by-side diff view. I hate that it's not working).

virtualdj commented 1 year ago

If you navigate away from the file after staging a selected range, it works.

Same here, this is the only workaround that works! VS Code version 1.83.1, Windows 10 22H2.

rgbmrc commented 11 months ago

Bump. For me the issue manifested recently, possibly after I disabled git.autofetch. I am not sure if it is related though, because I do not see how it should and because I re-enabled autofetch and the problem did not disappear.

Version: 1.84.2 (user setup)
Commit: 1a5daa3a0231a0fbba4f14db7ec463cf99d7768e
Date: 2023-11-09T10:51:52.184Z
Electron: 25.9.2
ElectronBuildId: 24603566
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Windows_NT x64 10.0.22621

darkvertex commented 9 months ago

I commented in 2022 and I'm back now in 2024 to say I'm still regularly experiencing troubles staging additional lines after staging some. Sometimes it forgets what I staged and instead of staging additional lines on top of what was previously staged, the selective staging overrides the currently staged contents for that file entirely, making it kinda pointless for complicated staging operations.

I've also noticed it gets confused by multiple cursors if you try to stage lines from many places/selections/cursors and only stages the first selection properly, if at all.

I'm so annoyed at this point if I have anything complicated to stage I just open the Terminal and run gitui instead. :/

Version: 1.85.1 (user setup)
Commit: 0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2
Date: 2023-12-13T09:49:37.021Z
Electron: 25.9.7
ElectronBuildId: 25551756
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Windows_NT x64 10.0.22621

dongseok0 commented 9 months ago

Same issue here - it doesn't work at all

Version: 1.85.2 (Universal)
Commit: 8b3775030ed1a69b13e4f4c628c612102e30a681
Date: 2024-01-18T06:40:32.531Z
Electron: 25.9.7
ElectronBuildId: 26354273
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Darwin arm64 22.5.0

jankap commented 8 months ago

Still broken

I'm pretty sure this has worked back in time. Now I just can't add multiple chunks and need to go the reverse way - git add the whole file and then unstage chunk by chunk. I'll test the unfocus workaround, too.

cartok commented 8 months ago

Feature broken? I can not stage removals line by line.

goshaaz commented 6 months ago

Still an issue for me

spencermathews commented 4 months ago

Something is still very buggy with "Stage Selected Changes".

I'm observing that the first block chosen does get staged, but subsequent changes do not get staged unless the diff editor is exited and re-entered.

yassine-safraoui commented 3 months ago

I just had this issue with Stage Selected Changes, when I try to run it after having selected some text it does not do anything, the work-arround I found was to first stage the whole block of the selection and then unstage the unwanted lines by selecting them and choosing Unstage Selected Ranges, at least that's somewhat acceptable if you only have a contiguous block to commit.

Note: I was facing issue when using VS code to write latex, maybe the LaTeX Workshop extension is related because I have it enabled but I really don't think so

microsoft / vscode

Stage Selected Ranges broken again? #147373