"Stage selected ranges" clobbers line endings for the entire file without any warning (Windows)

[EricCornelson]

• VSCode Version: Tested on 1.44.2 and 1.45.0 insiders
• OS Version: Windows 10 Build 18363

Steps to Reproduce:

1. Make any change in a file which has CRLF line endings in the git repository

2. Stage the change from the git diff UI in vscode using "stage selected ranges"

3. use git diff --staged to see the diff of the file (making sure diff.wsErrorHighlight is set to "all", otherwise you still can't see the changes), and see that the line endings for the entire file have now changed:
   

This is especially insidious if you happen to have core.autocrlf set to true, because the files will continue to look identical on disk when checked out, they will only differ in the repo itself (and when you go to submit a PR, it looks like the whole file changed, but github doesn't identify that the change is in the line endings, which can lead to lots of confusion when you look back on disk and see no change).

Also, the git diff UI in VS Code will not show the differences, even with Ignore Trim Whitespace set to false, which means the user has no idea that his line endings are being clobbered, potentially for weeks or months.

Does this issue occur when all extensions are disabled?: Yes, tested with a fresh install of latest stable (1.44.2) with no extensions

[vscodebot]

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

• Staging when ignoring whitespace, doesn't stage changed whitespace (#63397)

[joaomoreno]

This is strange. What crlf settings do you have set in git?

[EricCornelson]

Here's my gitconfig:

[diff "astextplain"]
	textconv = astextplain
[filter "lfs"]
	clean = git-lfs clean -- %f
	smudge = git-lfs smudge -- %f
	process = git-lfs filter-process
	required = true
[http]
	sslBackend = openssl
	sslCAInfo = C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
[core]
	autocrlf = true
	fscache = true
	symlinks = false
[credential]
	helper = manager

[joaomoreno]

Can you repro if you comment the autocrlf setting?

[frizikk]

I also have same problem.
Bug appear even autocrlf is set to false or commented..

[diff "astextplain"]
	textconv = astextplain
[filter "lfs"]
	clean = git-lfs clean -- %f
	smudge = git-lfs smudge -- %f
	process = git-lfs filter-process
	required = true
[http]
	sslBackend = openssl
	sslCAInfo = C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
[core]
	autocrlf = true
	fscache = true
	symlinks = true
	editor = \"C:\\\\Program Files\\\\Microsoft VS Code Insiders\\\\Code - Insiders.exe\" --wait
[credential]
	helper = manager

Version: 1.43.2 (system setup)
Date: 2020-03-24T07:38:38.248Z
Electron: 7.1.11
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.18363

Version: 1.45.0-insider (system setup)
Date: 2020-05-01T09:46:47.589Z (5 days ago)
Electron: 7.2.2
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.18363`

vscode git console output

> git hash-object --stdin -w --path app/Models/Product.php
> git show -s --format=%H%n%aN%n%aE%n%at%n%ct%n%P%n%B -z HEAD
> git ls-tree -l HEAD -- app/Models/Product.php
> git update-index  --cacheinfo 100644 c81711156998487019f211f025a8e04368ba0b92
 app/Models/Product.php
Ignoring path 
> git status -z -u
> git symbolic-ref --short HEAD
> git rev-parse master
> git rev-parse --symbolic-full-name master@{u}
> git rev-list --left-right master...refs/remotes/origin/master
> git for-each-ref --format %(refname) %(objectname) --sort -committerdate
> git remote --verbose
> git config --get commit.template
> git ls-files --stage -- C:\Users\xxx\xxx\app\Models\Product.php
> git cat-file -s c81711156998487019f211f025a8e04368ba0b92
> git show :app/Models/Product.php
> git status -z -u
> git symbolic-ref --short HEAD
> git rev-parse master
> git rev-parse --symbolic-full-name master@{u}
> git rev-list --left-right master...refs/remotes/origin/master
> git for-each-ref --format %(refname) %(objectname) --sort -committerdate
> git remote --verbose
> git config --get commit.template

[EricCornelson]

If I remove the autoclrf setting (and restart vscode) I do not see this issue.

However, I don't think disabling that setting is a great workaround. For Windows, setting autocrlf=true is the default (and recommended) setting when installing git.

[EricCornelson]

More clarification: this only happens on files which are stored in the repo with Windows (CRLF) line endings. Files in the (or any) repo with Unix line endings (just LF) are not affected.

So basically, this case happens if someone ends up committing a file to a repo without autoclrf=true (so you get windows line endings in one or more files in the repo).

Also confirmed that this does not happen when staging the chunk from git command line.

[wbt]

I am encountering this too, and it leads to a lot of rework because it leads to file-level conflict detection instead of being able to merge changes in on a line level.

When Atom's "stage selected ranges" works (it doesn't always), it doesn't have this issue, and the UI is way better to easily review and stage selected ranges. Atom is MIT-licensed and originally a project of GitHub which is now part of Microsoft; maybe some working Atom code could be reused in VSCode?

[hoihu]

I also encountered this problem. Seems to be an issue, still.

[francescoferraioli]

I've also encountered this problem. I've moved to using sourcetree for this sort of stuff. It's free and it doesn't have this bug.