Steps to Reproduce:
Expected result: initial encoding preserved
Actual result: encoding is set to UTF-8
Reproduces without extensions: Yes
Note: "files.encoding" and "files.autoGuessEncoding" settings of VScode doesn't affect anyhow on the result.
I have the same problem on VSCode Version: 1.18.0 - Insider, OS Version: Windows 10 and this problem also reproduces without extentions. As the my project requires only one file encoding, that's very uncomfortable for me to stage and commit file ranges using external programs like source tree.
Please take a look on this problem
if this bug is up for grabs, can I take this up?
As @kav137 describes, how can I"Check encoding of the staged file"?
These are the steps I performed
1) created a file with encoding "UTF8 With Bom", within my repo.
2) committed this file
3) using vs code, edited this file
4) under the "Source Control" tab, I selected this file
5) ran the command "Git: Stage Selected Ranges"
6) under the "Source Control" tab, Under the "Staged Changes" section, I select my file.
After this, I am unsure where to look for encoding of the file.
At the bottom-right of the vs code window, I see "Line 1, Col 1 Spaces: 4 Plain Text". But no mention of encoding.
@amitdey1987
I recorded the video which shows how you can reproduce this issue
Are there any news about this? I am working on a Windows-1252 file and using "Stage Selected Ranges" tries to read it UTF-8 (using git add --patch works correctly)
1.27.2 it looks like it's still broken.
I'm looking at this right now, it seems that is because it creates a new document to receive the changes, and the new document doen't refer to any encoding.
I'll need to find how to find the encoding from the current opened document to use the same to the newly created document.
As soon as I find something, I'll let you know
Unfortunately Stage Selected Ranges is unusable because of this problem. Our files are in UTF-8-BOM format and Stage Selected Ranges command strips BOM.
Are we waiting for #55110?
So I installed OSS Dev version of VSCode and fired debugger. The problem is in vscode\extensions\git\src\git.ts
async stage(path: string, data: string): Promise<void> {
const child = this.stream(['hash-object', '--stdin', '-w', '--path', path], { stdio: [null, null, null] });
child.stdin.end(data, 'utf8');
child.stdin.end() is always called with 'utf8', regardless of original file encoding.
Object is staged using git.exe hash-object --stdin -w --path test.cpp
@joaomoreno can you please give me some hint how to continue? Is original file encoding (including BOM/non-BOM information) available here? Thank you. I would really like to fix this problem, so we can use VSCode for interactive staging.
Problem is still occurring in 1.36.1.
@rysavyjan: can we just omit the encoding in this call?
This is an annoying issue, because when you go to view the changes on GitHub, it appears as if the entire file was modified, so you can't see what exactly changed. I'll have to keep using git add -p until this is fixed.
This has been fixed thanks to https://github.com/microsoft/vscode/issues/55110
Verification:
Current stable (broken):

Fixed:

Most helpful comment
So I installed OSS Dev version of VSCode and fired debugger. The problem is in vscode\extensions\git\src\git.ts
child.stdin.end() is always called with 'utf8', regardless of original file encoding.
Object is staged using
git.exe hash-object --stdin -w --path test.cpp@joaomoreno can you please give me some hint how to continue? Is original file encoding (including BOM/non-BOM information) available here? Thank you. I would really like to fix this problem, so we can use VSCode for interactive staging.