-
Notifications
You must be signed in to change notification settings - Fork 60
Description
Content committed to git by all apps, and then retrieved specifically by wslgit -> results in that content appearing to be improperly altered. Specifically, any lines which start with text similar to a Unix path are blindly changed to a DOS path.
Setup
- Windows 10 FCU
- WSL installed with Ubuntu with current apt updates
- Git v2.16.1 in WSL ubuntu
- VS Code v1.19.3
- WSLgit v0.50 installed properly in VS Code
Repro
- Using command line tools, create an empty directory
- Using command line tools,
git init
- Using any tool except for VS Code, create a file in that directory named "test1.py"
- Using any tool except for VS Code, edit that file to have the following content
text="""This is a test case
/mnt/c/mypath/myfile.txt
and the end of the string"""
- Using command line tools,
git add test1.py
- Using command line tools,
git commit
- Run VS Code
- Open the folder you created in step 1
- Double-click the file test1.py so that VS Code opens it for editing
- Add three a's on the end of the first line, so that it reads
text="""This is a test caseaaa
- Save the file
- Notice the source control icon on the left navigation bar indicates there is one change.
- Click on that source control icon
- Click on test1.py to see the changes
Result
VS Code shows two lines have changed.
It correctly shows the line with the added aaa
It incorrectly shows the second line as being changed due to the blind transformation
Expected
VS Code shows one line has changed. The line with the added aaa
.
Notes
Easy to see this with the changes/diff in VS Code. VS Code uses the git show
command. You can see it in VS Code's git output window. I am not familiar enough with the output from the numerous git commands and how VS Code uses them to suggest a solid fix. Instead, I have some observations and an idea to explore.
When a new folder is opened in VS Code, there is a common sequence of commands that VS Code issues to git. Below is an example. In this list, I think only one command config --get commit.template
returns a path on column 0. And if it does, we do want to convert the path.
git --version
git rev-parse --show-toplevel
git config --get commit.template
git status -z -u
git symbolic-ref --short HEAD
git rev-parse master
git check-ignore -z --stdin
git rev-parse --symbolic-full-name --abbrev-ref master@{u}
git for-each-ref --format %(refname) %(objectname)
git remote --verbose
When you click on a file in the source control section of VS Code, the following is an example. Both of the show
commands are at risk.
git for-each-ref --format %(refname) %(objectname)
git remote --verbose
git ls-tree -l HEAD -- c:\repos\wslgitbug\test1.py
git show 5f3996d985119c78ba391c7dd4c25e6aa8853675
git show HEAD:test1.py
When you stage a file. I think only the show
command is at risk
git add -A -- c:\repos\wslgit\src\main.rs
git status -z -u
git show :src/main.rs
git symbolic-ref --short HEAD
git rev-parse no-blind-path-changes
git rev-parse --symbolic-full-name --abbrev-ref no-blind-path-changes@{u}
git for-each-ref --format %(refname) %(objectname)
git remote --verbose
When you commit, again the show
command is at risk.
git commit --quiet --allow-empty-message --file -
git status -z -u
git show :src/main.rs
git symbolic-ref --short HEAD
git rev-parse no-blind-path-changes
git rev-parse --symbolic-full-name --abbrev-ref no-blind-path-changes@{u}
git for-each-ref --format %(refname) %(objectname)
git remote --verbose
git config --get commit.template
When push to github, again the show
command is at risk
git push -u origin no-blind-path-changes
git status -z -u
git show :src/main.rs
git symbolic-ref --short HEAD
git rev-parse no-blind-path-changes
git rev-parse --symbolic-full-name --abbrev-ref no-blind-path-changes@{u}
git rev-list --left-right no-blind-path-changes...origin/no-blind-path-changes
git for-each-ref --format %(refname) %(objectname)
git remote --verbose
Then sync to github, again the show
command is at risk
git pull
git show :src/main.rs
git status -z -u
git show :src/main.rs
git symbolic-ref --short HEAD
git rev-parse no-blind-path-changes
git rev-parse --symbolic-full-name --abbrev-ref no-blind-path-changes@{u}
git rev-list --left-right no-blind-path-changes...origin/no-blind-path-changes
git for-each-ref --format %(refname) %(objectname)
git remote --verbose
Workarounds
Looking at just those examples, it is the show
command which should never alter paths on lines as they are returned from WSL via stdout. I might suggest creating a const static array in the WSLgit codebase. This array holds commands which should skip the call .map(translate_path_to_win)
.
I have a commit which implements this idea.