vscode: Git does not work when VS code is open
Issue Type: Bug
Recent updates to VS Code have caused git to fail most of the time.
Most of the time I cannot:
- add files to staging with
git add filename
, - commit staged files with
git commit
, - push to remote with
git push
.
It does not matter whether I execute these commands from the integrated terminal (gitbash, PowerShell, or cmd) , a stand alone terminal (gitbash, PowerShell, or cmd), or from the git tools integrated in VS Code. All attempts results in the same errors.
The most common error occurs when running git add
or git commit
, which is:
fatal: fsync error on 'loose object file': Bad file descriptor
When running git gc
I get:
fatal: fsync error on '.git/objects/pack/tmp_pack_sztM1a': Bad file descriptor
fatal: failed to run repack
There are other errors, I will post here when I get them again.
This has happened occasionally before, but now it is nearly constant.
The only way to get git to work is to close all open instances of VS Code and run the git commands from a separate terminal. This is a irritating impediment.
If there is no way around this, is there a way to completely block all VS Code git integration?
VS Code version: Code 1.46.1 (cd9ea6488829f560dc949a8b2fb789f3cdc05f5d, 2020-06-17T21:13:20.174Z) OS version: Windows_NT x64 10.0.17763
System Info
Item | Value |
---|---|
CPUs | Intel® Core™ i5-6300U CPU @ 2.40GHz (4 x 2496) |
GPU Status | 2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: disabled_off protected_video_decode: unavailable_off rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled viz_display_compositor: enabled_on viz_hit_test_surface_layer: disabled_off_ok webgl: enabled webgl2: enabled |
Load (avg) | undefined |
Memory (System) | 15.88GB (5.77GB free) |
Process Argv | |
Screen Reader | no |
VM | 0% |
Extensions (5)
Extension | Author (truncated) | Version |
---|---|---|
better-toml | bun | 0.3.2 |
macros | ged | 1.2.1 |
sftp | lix | 1.12.9 |
python | ms- | 2020.6.89148 |
rust | rus | 0.7.8 |
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 16 (7 by maintainers)
https://stackoverflow.com/q/47929881/1156119 looks similar which says it could be low disk space, permissions or not using mapped drives? The only thing I can think of is this is a limitation of winpty and you need to update to the new terminal backend which is maintained by Microsoft so weird permissions-related things like this don’t happen, you need to be on Windows 1903+ to use the new system.