Closed rcarmo closed 6 years ago
Vscode could have Git auto-detection for Windows from different sources:
- Program Files\Git
- Visual Studio Git
- Cygwin git could be auto-detected by its exe file location
It may be hardcoded preference or highest version preferred.
Yet again - this is not about git.exe location, it is about Cygwin paths support.
Yes, I got it @AnrDaemon Could you try to run Cygwin's git from cmd by its Windows path, please?
Yes, you could. That's not the problem. The problem starts when Cygwin Git return Cygwin paths which VS Code don't know how to interpret. Or when VS Code provide Windows paths that means nothing to Cygwin Git.
It requires some extra care inside VS Code itself, and even then not fully fool proof, as other extensions may run Git directly by themselves.
@AnrDaemon Yep. it's not just the difference in slashes, absolute paths and cygwin start with /cygdrive/<drive letter>
and in Windows, start with <drive letter>:\\
. The last paragraph in your comment is especially tricky.
Here's my workaround, and I didn't come up with it on my own. In fact, I may be summarizing something already in this thread.
settings.json
: "git.path": "C:\\cygwin64\\home\\<user>\\vscode_git_compatibility\\cygpath-git-vscode.bat",
.$ cat cygpath-git-vscode.bat
:
@echo off
REM wrapper to convert linux paths to windows
REM so vscode git integration will work with cygwin
REM "git.path"="C:\\this\\file.bat" in settings.json
setlocal
set PATH=C:\cygwin64\bin;%PATH%
if "%1" equ "rev-parse" goto rev_parse
git %*
goto :eof
:rev_parse
for /f %%1 in ('git %*') do cygpath -w %%1
I don't know why, and I don't know if it's actually used (running ag -l 'cygpath-git-editor.sh'
in my home directory finds nothing), but I have another file in C:\\cygwin64\\home\\<user>\\vscode_git_compatibility\\
named cygpath-git-editor.sh
. $ cat cygpath-git-editor.sh
:
#!/bin/bash
# wrapper to convert linux paths to windows
# so vscode will work as a git editor with cygwin
# editor="/home/this/file.sh" in .gitconfig
# extract last argument (the file path)
for last; do true; done
# get all the initial command arguments
all="${@:1:$(($#-1))}"
# launch editor with windows path
code $all $(cygpath -w $last)
I'm kind of in a rush so I don't have the time to verify if these are the only steps, but it is what I currently use. I hope this can be of help to someone. I want to reiterate that @AnrDaemon 's last paragraph still applies.
The workaround is to install Git-For-Windows in a separate directory and point VS Code to it.
The workaround is to install Git-For-Windows in a separate directory and point VS Code to it.
Are providing an alternative workaround or explaining mine?
Restating the obvious.
Restating the obvious.
Not obvious enough, it seems. It looks like you said this back in 2022, but I hadn't noticed until now. The next reply provides a different workaround that may have buried yours.
If you use the git-for-windows work around, can you still use cygwin's git
in the same project, or do they step on each other's toes? I use the git command line 95% of the time; I only need VS Code to understand enough to mark my files as modified.
I do.
Cygwin is my go-to *NIX tools, I only install native ports/equivalent tools when one of the following statements is true:
Steps to Reproduce:
git.path
to point to"\\cygwin64\\bin\\git.exe
ENOENT: no such file or directory, lstat 'C:\cygdrive'
, as described hereThis is, of course, because Cygwin namespaces the filesystem differently. However, doing this (which usually fixes things in other tools):
...then results in further confusion as Code apparently does not have a way to correctly set the environment for the git process, which then defaults to the wrong PATH:
Trying to set PATH, HOME, etc. inline in the
bash
command line above fails for some reason I cannot yet fathom, but I would suggest a configuration settinggit.env
be created so that the environment external Git tools can be pre-configured (this would also benefit the Linux and OSX ports).As to why this is necessary and why I can't use other Git binaries on Windows, the reason is simple:
Cygwin does Git over SSH "right", with completely identical setup in terms of SSH keys, options, CR/LF encoding, etc. Current Git for Windows simply does not work for my use case (I've tried), and, obviously, the Linux Subsystem doesn't help with this either.