Microsoft/vscode

Git - Revert changes on a hunk sometimes corrupt entire files

Open

#77,828 建立於 2019年7月23日

在 GitHub 查看
 (0 留言) (0 反應) (1 負責人)TypeScript (74,848 star) (10,221 fork)batch import
buggithelp wanted

描述

  • VSCode Version: 1.35.1
  • OS Version: Fedora 30
  • git version: 2.21.0

Steps to Reproduce:

There are no steps to easily reproduce this bug. Once it happens, I can reproduce it until I restart VSCode. Restarting code does "fix" this until it happens again. It has been happening to me about once a month for over a year since well before 1.34.0. I am constantly updating vscode, and the bug constantly keeps happening. When it does happen:

  1. I click in the gutter to see the git differences
  2. I decide I want to revert that line and then
  3. Changes all over the file are applied. While I can "undo", this can be dangerous when I don't notice the entire file was just corrupted.
  4. Ctrl+Z and repeating will cause it to happen again and again. So once it happens, it is repeatable until I restart VSCode

I do a lot of git on the CLI, but I can't figure out if I do anything to make this happen. In this particularly well documented case, here's what happened this time:

  1. I have been editing a lot of files, adding and committing from the git CLI
  2. The git status was clean, no uncommitted changes.
  3. I opened executor.py and I notices that the gutter said I had 7 hunks modified through out the file. I thought that was odd, since I knew my git environment was clean, and so I "viewed" the hunks to see what the changes were.
  4. The totality of the changes were from changes that I committed on The 22nd, 19th, and 17th
    1. I started VSCode at 1:15 PM on July 17th.
    2. I believe I also rebased this particular branch on July 17th too. I'm fuzzy on the exact timing for that.
  5. I saw the 7 changes, reverted one, and noticed I got this same file corruptuption error that I've been trying to replicate so I can make this issue. I saved:
  • The original file The file as it was committed on the 22nd
  • The file1 after I reverted the very first hunk change, which should have just been a space
  • The file2 after I Ctrl+Z the previous and reverted just the second hunk change
  • The file3 after only the third hunk
  • The file4 after only the forth hunk

If you diff these, you will see that ever hunk that I didn't revert, was duplicated on a later line. This has happened to me several times in the past, and the effects are not always as trivial.

For example, the diff from the original to file1 should be

59c59
<                       'implementation changed?')
---
>                        'implementation changed?')

But is instead

61c61
<         # Is not running nor revoked nor finished :/
---
>                        'implementation changed?')
129c129
<             if not fut.cancel():  # pragma: no cover
---
>           logger.debug1('Celery task "%s" canceled.', ar.id)
137c137
<             fut.set_running_or_notify_cancel()
---
>           logger.debug1('Celery task "%s" running.', ar.id)
143c143
<           # Future is FINISHED
---
>           logger.debug1('Celery task "%s" resolved.', ar.id)
148c148
<           # Future is FINISHED
---
>           logger.debug1('Celery task "%s" resolved with error.', ar.id)
194c194
<         pass
---
>       except RuntimeError:  # pragma: no cover

Notice: The line numbers are off by 2

Other info:

  • I'm working in a submodule, I'm almost always working with submodules
  • The "Source Control" pan in VSCode shows the correct branch name for the submodule, unit19_rebase1
  • I do have GitLens, but this part of vscode is unrelated to GitLens
  • The ↻ in the git window doesn't help any.
  • I checked out detached head, and now the Source Control Providers area shows the correct sha, not just the branch name. So VSCode does know the right sha, but still produces this error
  • I closed the file and opened it again (Leaving VSCode open the whole time) and the problem continues to reproduce.
  • Restarting VSCode did make the problem go away (until it happens again)

Does this issue occur when all extensions are disabled?: Cannot test, as this bug is too rare, and restarting makes it go away until the next time it occurs. Currently, I've been running VSCode for 5 days (no sleep or hibernation)

貢獻者指南