-
Notifications
You must be signed in to change notification settings - Fork 28.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Stage selected ranges" clobbers line endings for the entire file without any warning (Windows) #96104
Comments
(Experimental duplicate detection) |
This is strange. What |
Here's my gitconfig:
|
Can you repro if you comment the |
I also have same problem.
vscode git console output
|
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? |
I also encountered this problem. Seems to be an issue, still. |
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. |
Steps to Reproduce:
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
The text was updated successfully, but these errors were encountered: