microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
163.73k stars 29.09k forks source link

Support cygwin git #7998

Closed rcarmo closed 6 years ago

rcarmo commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 GITAUTHOR* and GITCOMMITTER* 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 commented 8 years ago

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:

samiworks commented 8 years ago

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 commented 8 years ago

@rcarmo Did you try this?

rcarmo commented 8 years ago

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 notifications@github.com 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.

samiworks commented 8 years ago

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

rcarmo commented 8 years ago

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 notifications@github.com 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 commented 8 years ago

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

rcarmo commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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:

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  git@github.com:rcarmo/azure-REDACTED.git (fetch)
origin  git@github.com:rcarmo/azure-REDACTED.git (push)
slepkaviba commented 7 years ago

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 commented 6 years ago

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 commented 6 years ago

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

neontorrent commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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:

DraconPern commented 6 years ago

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 commented 6 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.

neontorrent commented 5 years ago

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 commented 5 years ago

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.

neontorrent commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

lalawue commented 4 years ago

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

dmak commented 3 years ago

Just tried the script from Cygwin Git + VS Code compatibility and it didn't work with the following error message in Git output:

> git ls-files --stage -- D:\Workspace\test\platformio.ini
fatal: D:\Workspace\test\platformio.ini: 'D:\Workspace\test\platformio.ini' is outside repository at '/cygdrive/d/Workspace/test'

@nukata Many thanks for your contribution, it works. Just one minor remark: what about re-writing the script on bash? bash is for sure present on all installations and most are familiar with it. I am not sure if I did this rewriting correctly as I couldn't test the script thoroughly for the case when wrap_output=yes, but here it goes:

#!/bin/bash

wrap_output=""
argv=("$@")

for ((i = 0; i < $#; i++))
do
    arg="${argv[$i]}"
    if [ $i = 0 -a "$arg" = 'rev-parse' ]
    then
        wrap_output=yes
    elif [[ -n "$arg" && "$arg" != -* ]]
    then
        argv[i]=`cygpath -u "$arg"`
    fi
done

if [ $wrap_output ]
then
    if out=`git "${argv[@]}"`
    then
        if [ -n "$out" ]
        then
            if [[ $out = -* ]]
            then
                echo "$out"
            else
                cygpath -w "$out"
            fi
        fi
    else
        x=$?
        echo "$out"
        exit $x
    fi
else
    exec /usr/bin/git "${argv[@]}"
fi
ViPod5 commented 3 years ago

@dmak Thank you! Great work, just one tiny adjustment. Either initially prefix the PATH with /usr/bin or change the git execs to /usr/bin/git or you'll end up with an infinite loop within the script.

DanKaplanSES commented 3 years ago

@joaomoreno Clarification: if someone were to submit a PR to fix this, would it be rejected considered?

I'm asking because if you would conditionally accept a PR, technically, shouldn't this issue remain open?

danfly09 commented 2 years ago

But why is it complicated to have git integration with VSCode? In my particular case, I don't think I have a problem with the path. It seems that VSCode can detect that I have an installation of git and that's because I added to PATH my cygwin bin folder, and then I can execute git commands from CMD and PowerShell without issues.

However, the editor fails to track the repositories completely.

AnrDaemon commented 2 years ago

This is because git reporting paths unexpected to VS Code. Plus it is reporting them inconsistently. Sometimes relative, sometimes absolute, from the same command. This is not a simple issue, unfortunately.

danfly09 commented 2 years ago

src/base/common/process.ts

// Native sandbox environment
if (typeof globals.vscode !== 'undefined' && typeof globals.vscode.process !== 'undefined') {
    const sandboxProcess: INodeProcess = globals.vscode.process;
    safeProcess = {
        get platform() { return sandboxProcess.platform; },
        get arch() { return sandboxProcess.arch; },
        get env() { return sandboxProcess.env; },
        cwd() { return sandboxProcess.cwd(); }
    };
}

I was wondering if an additional check can be made here so if sandboxProcess.platform is win32, then check for a Cygwin installation, this can be checked by executing the command, cygcheck --version Cygwin bin folder needs to be added to the Path variable. A user configuration variable can also do the work of checking whether VSCode should run natively or under a Cygwin session.

In that scenario get platform() { return linux } instead of win32 I believe the compatibility for a real linux OS should then work.

Another option might be a container, but I have no experiencie with VScode containers or extensions, but the idea is there, to be implemented.

AnrDaemon commented 2 years ago

You can have multiple Cygwin environments installed on the same PC. And none of them in the $PATH. I've long since abandoned the hope and installed Git-for-Windows (and told VS Code to use specifically that one).

ViPod5 commented 2 years ago

I've been using this https://github.com/nukata/cyg-git with success.

On Sat, Apr 16, 2022 at 2:41 PM AnrDaemon @.***> wrote:

You can have multiple Cygwin environments installed on the same PC. And none of them in the $PATH. I've long since abandoned the hope and installed Git-for-Windows (and told VS Code to use specifically that one).

— Reply to this email directly, view it on GitHub https://github.com/microsoft/vscode/issues/7998#issuecomment-1100655030, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADM6ZK73Q6EIR2CQEYNIWVLVFKYPZANCNFSM4CHOZKKQ . You are receiving this because you commented.Message ID: @.***>

maksim-pinguin commented 2 years ago

as noted in #148720 i believe supporting the configured integrated terminal is the way to go. extensions like gitlense do this e.g.

AnrDaemon commented 2 years ago

This is not enough. Cygwin paths are inherently different from Windows paths, and VS Code do not understand that distinction.

ohhmm commented 9 months ago

Vscode could have Git auto-detection for Windows from different sources:

It may be hardcoded preference or highest version preferred.