Skip to content

file content changed by blind path transformations #19

@diablodale

Description

@diablodale

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

  1. Using command line tools, create an empty directory
  2. Using command line tools, git init
  3. Using any tool except for VS Code, create a file in that directory named "test1.py"
  4. 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"""
  1. Using command line tools, git add test1.py
  2. Using command line tools, git commit
  3. Run VS Code
  4. Open the folder you created in step 1
  5. Double-click the file test1.py so that VS Code opens it for editing
  6. Add three a's on the end of the first line, so that it reads text="""This is a test caseaaa
  7. Save the file
  8. Notice the source control icon on the left navigation bar indicates there is one change.
  9. Click on that source control icon
  10. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions