microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
164.43k stars 29.34k forks source link

"Stage selected ranges" sometimes stages a revert of changes in the previous commit #64027

Open sobjornstad opened 5 years ago

sobjornstad commented 5 years ago

I am not able to test with the insiders build as I don't have permission to install unauthorized software versions on my workstation here.

Steps to Reproduce:

(Since this seems to be kind of finicky, I've added more details about how I select things and so on than I would ordinarily provide.)

  1. Change two different locations in a file.
  2. Select the changed lines in one location (with the mouse) and choose Git: Stage Selected Ranges from the palette (I open it with Ctrl-Shift-P).
  3. Fill in a commit message and commit the change by pressing Ctrl-Enter.
  4. Click off the previous selection and select the other change. Again choose Git: Stage Selected Ranges from the palette. Do not do anything else in between (sometimes the issue does not occur if you do other things).
  5. View the staged changes. In addition to the newly staged lines, an exact revert of the previous changes is present. This does get committed if you then commit, and it shows up in git diff --cached.

This happens pretty reliably, but only happened 75% of the times I was trying to reproduce it -- I assume I was doing something else in between or selecting something in a slightly different way the times it didn't happen.

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

Git output

VSCode appears to be doing a lot of extra stuff the second time!

On staging the first change:

> git show HEAD:git training/Activities/activities.md
> git hash-object --stdin -w --path git training/Activities/activities.md
> git ls-tree -l HEAD -- git training/Activities/activities.md
> git update-index --cacheinfo 100644 3592ee3adb9657ed0ef318abc491cbc19969d7b5
 git training/Activities/activities.md
> git status -z -u
> git symbolic-ref --short HEAD
> git rev-parse pilot/master
> git rev-parse --symbolic-full-name pilot/master@{u}
> git rev-list --left-right pilot/master...refs/remotes/origin/pilot/master
> git for-each-ref --format %(refname) %(objectname) --sort -committerdate
> git remote --verbose
> git show :git training/Activities/activities.md

On staging the second change:

> git hash-object --stdin -w --path git training/Activities/activities.md
> git ls-tree -l HEAD -- git training/Activities/activities.md
> git update-index --cacheinfo 100644 a4df3ae5acc9dfee9d7b33e8608581ca640715eb
 git training/Activities/activities.md
> git status -z -u
> git symbolic-ref --short HEAD
> git rev-parse pilot/master
> git rev-parse --symbolic-full-name pilot/master@{u}
> git rev-list --left-right pilot/master...refs/remotes/origin/pilot/master
> git for-each-ref --format %(refname) %(objectname) --sort -committerdate
> git remote --verbose
> git show :git training/Activities/activities.md
> git ls-tree -l HEAD -- c:\Workspaces\Temp\toolslang_tfs_training\git training\Activities\activities.md
> git ls-tree -l HEAD -- c:\Workspaces\Temp\toolslang_tfs_training\git training\Activities\activities.md
> git show 29fdbfdab2573936bf25f93dc9d00e36c3079920
> git ls-files --stage -- c:\Workspaces\Temp\toolslang_tfs_training\git training\Activities\activities.md
> git show 29fdbfdab2573936bf25f93dc9d00e36c3079920
> git ls-files --stage -- c:\Workspaces\Temp\toolslang_tfs_training\git training\Activities\activities.md
> git cat-file -s a4df3ae5acc9dfee9d7b33e8608581ca640715eb
> git cat-file -s a4df3ae5acc9dfee9d7b33e8608581ca640715eb
> git show a4df3ae5acc9dfee9d7b33e8608581ca640715eb
> git show a4df3ae5acc9dfee9d7b33e8608581ca640715eb
> git show HEAD:git training/Activities/activities.md
> git show :git training/Activities/activities.md
vscodebot[bot] commented 5 years ago

(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

joaomoreno commented 5 years ago

I'm pretty sure this can happen if VS Code fails to refresh the index version of the file in time for that second stage... 👍 Good catch

lukas-lang commented 5 years ago

Any update on this/did anyone find a workaround for this?

I have this issue (the one described in #63386 to be more precise) with one of my repositories and it makes it very difficult to create clean commits... The "good" news is that it seems to happen reliably only in one repo and not another one, so if I can test anything/provide some logs, I would be happy to help to track down the cause

odyniec commented 5 years ago

I'm also experiencing this issue (VSCode version 1.31.0 on Ubuntu 18.04). Unfortunately it can lead to a mess in commit history...

Edit: It appears reloading the window (Shift+Ctrl+P "Reload Window") fixes the problem (well until the next occurrence).

wesinator commented 5 years ago

Edit: It appears reloading the window (Shift+Ctrl+P "Reload Window") fixes the problem (well until the next occurrence).

Reloading the window is not fixing it for me. Code 1.36.1 on macOS 10.14.5 Just started noticing issues recently

between this and https://github.com/microsoft/vscode/issues/63397 (which does have a workaround thank God), VS code git is not functional for me right now.

Moving to atom until this mess gets fixed.