Vscode: Support cygwin git

[rcarmo]

• VSCode Version: 1.2.1
• OS Version: Windows 10 Build 14367

Steps to Reproduce:

1. Install Cygwin
2. Edit .vscode/settings.json to set git.path to point to "\\cygwin64\\bin\\git.exe
3. VS Code throws up an error message of ENOENT: no such file or directory, lstat 'C:\cygdrive', as described here

This is, of course, because Cygwin namespaces the filesystem differently. However, doing this (which usually fixes things in other tools):

        "git.path": "\\cygwin64\\bin\\bash.exe git",

...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:

git fetch
git show HEAD:.vscode/settings.json
git show HEAD:.vscode/settings.json
Could not create directory '/c/cygwin64/home/USERNAME/.ssh'.
ssh_askpass: exec(/usr/local/bin/win-ssh-askpass.exe): No such file or directory
Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
git fetch
Could not create directory '/c/cygwin64/home/USERNAME/.ssh'.
ssh_askpass: exec(/usr/local/bin/win-ssh-askpass.exe): No such file or directory
Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

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 setting git.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.

[joaomoreno]

Duplicate of #7361. We don't support cygwin git, sorry.

We've been using Git for Windows successfully in the team, complete with SSH keys, options, line ending encodings et al. What is the actual issue you get with it?

[rcarmo]

Hmmm. So this is a dupe of a ticket that's closed because we've "just never really looked into it"?

My issue is that I can use _exactly_ the same setup with Cygwin than on Linux without having to sort out the (rather clunky) Git for Windows options and separate management of SSH keys. It's just less friction for someone who has to work routinely on both environments. Personally, I would very much like _not_ to have to use Git for Windows _at all_ and just rely on the Cygwin binaries.

Also, you missed my suggestion of adding a git.env setting to set the environment for Git binaries, which is also useful on other platforms. Should I file an issue for that separately?

[joaomoreno]

If #7361 were open we would close this one the same way. It is a duplicate, in any case.

Apologies for coming out harsh.

Let me expand a bit on _just never really looked into it_. Code already needs to support whichever version of git you have installed in whichever platform you are using it. It is a non-trivial task that gets another complexity fold as soon as we add git _flavours_. We've found that Git for Windows handles the great majority of the tasks users need and I've personally have yet to find a reason that would make me use cygwin instead.

Of course, I can be wrong and I'm definitely interested in someone proving me wrong. That's why I asked about the actual issue you face. If it is really something Git for Windows does not support, of course we'll reconsider our position towards cygwin, and we'll work towards that.

[rcarmo]

It's all about integration. When you use Cygwin and its userland (bash, CLI tools, SSH, etc.), you don't need an extra terminal emulator like PuTTY, you can use standard Git plugins that rely on Perl/Python etc. seamlessly, and you don't need to set up a copy of your SSH keys anyplace else.

Right now, the current (stunted and incomplete) UNIX userland clone that ships with Git for Windows doesn't provide me those affordances. Also, I can't set GIT_AUTHOR_* and GIT_COMMITTER_* on a per-repo basis using Git for Windows - it's just a surreal amount of pain to deal with that kind of thing inside it, when it all works perfectly in Cygwin.

With an environment setting I might not only actually get Cygwin Git to work (I suspect it's just a matter of setting the right HOME and a few more variables) but also have GIT_* settings set on a per-project basis for me inside VS Code. And this last bit will benefit every other platform, too.

[joaomoreno]

Alright, let's keep this open for tracking the support. A PR would be much appreciated as we'll likely not have cycles to look into it any time soon.

Maybe next time I'm in the Lisbon office, I'll ping you and we'll get it working in an afternoon. :wink:

[Rigg802]

I created a symlink and it worked for me:
http://stackoverflow.com/questions/36508177/visual-studio-code-cannot-detect-cygwin-git-exe-path/37980938#37980938

[joaomoreno]

@rcarmo Did you try this?

[rcarmo]

Not yet, kind of tied up with FY16 still. Will give it a go next weekend and see if it works on my box and a fresh install (never underestimate the power of upgrades where it regards breaking things).

On 04 Jul 2016, at 14:45 , João Moreno [email protected] wrote:

@rcarmo https://github.com/rcarmo Did you try this?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/Microsoft/vscode/issues/7998#issuecomment-230294069, or mute the thread https://github.com/notifications/unsubscribe/AAX96yMsQpPeoo5orUAdryk1tJMc5ipXks5qSQ5ggaJpZM4I7sqV.

[Rigg802]

someone had a similar issue here too and it worked: https://github.com/Microsoft/vscode/issues/1982

[rcarmo]

I'm going to have a go at this (both reproducing and understanding _exactly_ why the symlink works, and if it works with my git plugins) within the next few days and will report back.

On 08 Jul 2016, at 19:32, Bastien Calestroupat [email protected] wrote:

someone had a similar issue here too and it worked: #1982

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[rcarmo]

Brief status update: I'm still having trouble with SSH/askpass at this point. Trying to debug.

[rcarmo]

I've been using it alongside Cygwin, and the answer is no. Unless I go full X-Windows and run VS Code inside LXSS, I can't get the degree of integration I need (plus the LXSS console is still not as nice as mintty, but that's beside the point here)

I made some headway recently using a little executable shim to wrap Cygwin's git, but I'm still missing something regarding PATH and environment variables. I still think being able to set environment variables prior to Git execution is the way around this, but time hasn't been on my side recently.

[jastorgalj]

Solution for me (Windows 10 - git from cygwin)
create dir - mkdir c:\cygdrive
open a cmd and goto - cd c:\cygdrive
créate link to c:\ - mklink /j "c" c:\
and ready..

[rcarmo]

That doesn't work for me for some reason - I get errors trying to find my home directory for SSH keys (Cygwin apparently gets confused and does stuff like /c/cygwin64/home/username/.ssh

[rcarmo]

I had partial success today by setting a couple of links and tweaking environment variables and managed to have Cygwin git do local commits, but there were two issues:

• the sync icon turned into a cloud+arrow icon (which means VSCode wasn't able to completely figure out the output from the Cygwin git binary). Pushing to the remote repo worked, but...
• ssh-ask-pass did not work correctly, and did not respect the environment variables set by ssh-agent (so I got an SSH password prompt on every git operation)

The second point essentially circles back to one of my earlier points - without being able to set environment variables for git within VS Code, this will likely always be broken in some way -- some people might get it to work with passwordless keys, but it's not a definitive solution.

Also (and this is just an aside), getting this to partially work completely broke "regular" Windows Git (which uses a variant of Cygwin):

git pull
      0 [main] ssh 9472 C:\Program Files\Git\usr\bin\ssh.exe: *** fatal error - add_item ("\??\C:\Program Files\Git", "/", ...) failed, errno 1
Stack trace:
Frame        Function    Args
000FFFF9BB0  0018007164E (00180273652, 00180224DD9, 000FFFF9BB0, 000FFFF8B30)
000FFFF9BB0  00180046669 (000FFFFABE0, 000FFFF9BB0, 1D21574853C4D14, 00000000000)
000FFFF9BB0  001800466A2 (000FFFF9BB0, 00000000001, 000FFFF9BB0, 505C3A435C3F3F5C)
000FFFF9BB0  001800DF22B (00000000000, 000FFFFCE00, 001800CEE68, 1D215748E2D2E24)

[joaomoreno]

The _cloud+arrow_ icon simply means the current branch you have checked out doesn't have an upstream branch configured. Once it does, it should show the sync icon. This must've been a coincidence that you checked out such a branch.

So... would it work if you set a few env variables for when Code calls git?

[rcarmo]

@joaomoreno: I believe so, yes. The experiment I did with an executable wrapper a while back was partially successful.

Maybe something like this would be feasible:

{
    "git.path": "..."
    "git.env": {
        "foo": "bar"
        ...
    }
}

[joaomoreno]

And are the variables predictable for each system? Meaning, could it simply be a git.cygwin: true setting and we just build it in?

[rcarmo]

Nope, I have to set _at least_ these for the SSH agent:

SSH_ASKPASS='C:\cygwin64\usr\local\bin\win-ssh-askpass.exe'
SSH_AUTH_SOCK=/tmp/ssh-59iOCz4fyxRZ/agent.12660

I can pin down SSH_AUTH_SOCK, but that's usually random, and I will need extra variables for some Git plugins and environments. Also, might be helpful to avoid future issues like #6202

[rcarmo]

Also, regarding the cloud+arrow bit, there's definitely something amiss here. I've tried Windows Git and Cygwin git on the same repo, same branch, no changes, and gotten:

• cloud+arrow for Cygwin git (and am unable to do git push)
• sync wheel for Windows git (and can do git push)

Might be a version issue (Cygwin git is 2.8.3), but you're right, VSCode can't figure out the remote for some reason.

$ git remote -v
origin  [email protected]:rcarmo/azure-REDACTED.git (fetch)
origin  [email protected]:rcarmo/azure-REDACTED.git (push)

[slepkaviba]

Is there any plan to add cygwin support? It is the only thing missing to make VSC perfect. (IntelliJ has no issue with their git, and I dont like having git-bash just to make VSC work...)

Looks like issue is caused by bizarre way of opening file:
git show :../../../../../../User/.......

As cygwin uses /home - file cant be reached. Why does it have to go all way up, to reach files again? Using relative - we can just go with absolute or relative to "opened folder" right? Or am I simplifying it?

[escalonn]

Warning for those using the kluges in the comments here - I was able to work with VSC okay (seemingly), but when I added VS to the mix, it wanted to change all permissions in opened folder a+x, while VSC then wanted to change them all a-x, so both programs could not see a clean working tree at the same time. Was not able to diagnose the issue further but that was enough for me to say "OK I'll use what is officially supported".

[rcarmo]

FWIW, it now sort of works with git inside the Linux Subsystem (aka Bash for Windows), although I keep having trouble with SSH auth.

[texasbruce]

Still broken as of today, for cygwin and msys

The workaround is @Radon222 's answer. VSC is trying to read the repo path from \home (msys) or \cygdrive (cygwin) and obviously it does not exist in windows. It should be a simple path conversion?

SSH is another issue, which is not quite related to Git itself

[rcarmo]

Well, no, but “proper” use of Git in many situations requires SSH key auth, and I, for one, vastly prefer it to auth helpers and HTTPS.

(I’m still using the built-in terminal to run bash and commit via the CLI, but in WSL now.)

[joaomoreno]

Sorry, guys, since this is just not a priority for us, I'm making the tough call to close this as out of scope, given that:

• Git for Windows is supported
• WSL support is tracked in #9502

[DraconPern]

For anyone that saw this thread doing a search on how to use Cygwin git and vscode, my solution was to install Git for Windows, and then use mklink to junction link the Cygwin .ssh directory to %USERNAME%/.ssh to share config and ssh key. Then both git will have access to the same ssh key and ssh config for multiple key usage. Also put the Cygwin\bin path first in environment.

[alignedfibers]

Hello All,

Linked below is a gist that wraps the Cygwin git.exe and converts the Linux paths which cause the error: "error while loading shared libraries: ?: cannot open shared object file: No such file or directory" to Windows paths using the cygpath executable.

https://gist.github.com/nickbudi/4b489f50086db805ea0f3864aa93a9f8

[nukata]

I think cyg-git might be able to solve the problem. It provides a "Git for Windows" virtually. You only need Cygwin and its packages.

https://github.com/nukata/cyg-git

[Omir85]

My 2 cents on this (I know, closed and aging) issue: I have added one environmental variable to include my cygwin bin folder to Windows path, and the warning message was removed after restarting VSCode.

[AnrDaemon]

Anybody's up for writing a small patch that would call cygpath -alm on the results of a few calls VS Code makes to Git that produce a full path as the result?
It's not really a rocket science for somebody familiar with VS Code internals.

[texasbruce]

Anybody's up for writing a small patch that would call cygpath -alm on the results of a few calls VS Code makes to Git that produce a full path as the result?
It's not really a rocket science for somebody familiar with VS Code internals.

I believe this is not an issue with cygpath. cygpath can produce correct windows path.

My assumption is vscode is using the wrong root path while parsing. I might be wrong though, since I didn't check the source code.

[AnrDaemon]

This is an issue between VS Code (which relies on git itself too much) and Cygwin git (which uses Cygwin directory layout, which follows POSIX FHS).
To make VS Code understand Cygwin paths, it should either be told to expect them, or use cygpath to convert them to native form.

[texasbruce]

This is an issue between VS Code (which relies on git itself too much) and Cygwin git (which uses Cygwin directory layout, which follows POSIX FHS).
To make VS Code understand Cygwin paths, it should either be told to expect them, or use cygpath to convert them to native form.

You can create a wrapper for that in Windows batch file, which calls cygpath to output windows path, and VSCode does not have to understand cygwin path, but it still does not work perfectly. The initial Git init works, but the file listing and diff do not work.

I briefly checked the VSCode before. When calling Git, it does not always use absolute path returned from Git command. It parses URI with a root path returned from other function, which does not seem to work properly with non official git binary. You can check that if you like.

[AnrDaemon]

Unfortunately, VS Code tries hard to find specifically "git.EXE", even if told to use "git.sh" wrapper (which has appropriate shell association defined).
I've had a small success with "git.cmd" wrapped around "git.sh", trying that route now.

[AnrDaemon]

However, a more native approach would be preferred.
Cygwin, despite its interoperability issues on filesystem level, has way better integration with Windows itself. In fact, better to the level that WSL could never achieve. Ever. Due to its nature.

[AnrDaemon]

You can create a wrapper for that in Windows batch file, which calls cygpath to output windows path

Now, I recalled why did I switch from CMD to TakeCommand/Console.
Insane, unusable quoting rules of CMD, compounded by inability to control arbitrary number of batch file parameters in an efficient way, are basically a showstopper to any effective scripting.

[igordcard]

Just adding myself here as another person who would really like to continue to use cygwin... + vscode.

[lalawue]

I think cyg-git might be able to solve the problem. It provides a "Git for Windows" virtually. You only need Cygwin and its packages.

https://github.com/nukata/cyg-git

it works for me under Win 7