0

I encountered an error when attempting to commit via the VSCode source control. The OUTPUT tab revealed that Git was searching for version.json (which is a symlink) with the incorrect path. After some research, I found a solution here. However, now I have version.json appearing in my diff, and when I try to open it, I receive the following message:

The editor could not be opened due to an unexpected error: Unable to read file 'c:/Users.../src/version.json (Unkown (FileSystemError): Error:EINVAL: invalid argument, readlink 'c:/Users.../src/version.json)''

Before reinstalling Husky, my Git was searching the file for the wrong path. When I undo the changes via source control, they start to appear in my git terminal (I'm running Ubuntu WSL).

$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        typechange: src/version.json

no changes added to commit (use "git add" and/or "git commit -a")

I attempted to reclone the project on the same path and encountered the same issue after running yarn There was a diff with an inaccessible file and a bug. Even when I used the checkout command or stash, the problematic file change reappeared in the source control.

Any ideias?

Edit:

Since a comment suggested it's a problem with hook configuration I'm adding it's config here to add more context, those are my package.json lines for the hook (rusky is running on version 4):

  "husky": {
    "hooks": {
      "pre-commit": "lint-staged",
      "pre-push": "CI=true yarn test"
    }
  },
  "lint-staged": {
    "src/**/*.{js,jsx,ts,tsx}": [
      "eslint --fix"
    ],
    "src/**/*.{css,js,jsx,ts,tsx}": [
      "prettier --write"
    ]
  },
Bernardo Marques
  • 925
  • 2
  • 10
  • 33

1 Answers1

0

I discovered a solution to the issue by recloning the repo. This time, instead of using the Clone with SSH option as paste address through my WSL terminal, I chose the Visual Studio Code (SSH) option.

This change appears to have enabled the Visual Studio Code's source control to properly handle the symlink, thereby resolving the confusion that existed between wsl/git/terminal and vscode/git/source control.

Bernardo Marques
  • 925
  • 2
  • 10
  • 33