Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support cygwin git #7998

Closed
rcarmo opened this issue Jun 22, 2016 · 40 comments
Closed

Support cygwin git #7998

rcarmo opened this issue Jun 22, 2016 · 40 comments

Comments

@rcarmo
Copy link

@rcarmo rcarmo commented Jun 22, 2016

  • 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
Copy link
Member

@joaomoreno joaomoreno commented Jun 22, 2016

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?

@joaomoreno joaomoreno closed this Jun 22, 2016
@rcarmo
Copy link
Author

@rcarmo rcarmo commented Jun 22, 2016

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
Copy link
Member

@joaomoreno joaomoreno commented Jun 22, 2016

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
Copy link
Author

@rcarmo rcarmo commented Jun 22, 2016

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
Copy link
Member

@joaomoreno joaomoreno commented Jun 22, 2016

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

@joaomoreno joaomoreno reopened this Jun 22, 2016
@joaomoreno joaomoreno changed the title Cannot use Cygwin git binary Support cygwin git Jun 22, 2016
@joaomoreno joaomoreno modified the milestones: July 2016, Backlog Jun 22, 2016
@joaomoreno
Copy link
Member

@joaomoreno joaomoreno commented Jul 4, 2016

@rcarmo Did you try this?

@rcarmo
Copy link
Author

@rcarmo rcarmo commented Jul 4, 2016

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 #7998 (comment), or mute the thread https://github.com/notifications/unsubscribe/AAX96yMsQpPeoo5orUAdryk1tJMc5ipXks5qSQ5ggaJpZM4I7sqV.

@Rigg802
Copy link

@Rigg802 Rigg802 commented Jul 8, 2016

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

@rcarmo
Copy link
Author

@rcarmo rcarmo commented Jul 8, 2016

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
Copy link
Author

@rcarmo rcarmo commented Jul 15, 2016

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

@rcarmo
Copy link
Author

@rcarmo rcarmo commented Jul 30, 2016

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
Copy link

@jastorgalj jastorgalj commented Sep 7, 2016

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
Copy link
Author

@rcarmo rcarmo commented Sep 22, 2016

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
Copy link
Author

@rcarmo rcarmo commented Sep 23, 2016

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
Copy link
Member

@joaomoreno joaomoreno commented Sep 23, 2016

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
Copy link
Author

@rcarmo rcarmo commented Sep 23, 2016

@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
Copy link
Member

@joaomoreno joaomoreno commented Sep 23, 2016

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
Copy link
Author

@rcarmo rcarmo commented Sep 23, 2016

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
Copy link
Author

@rcarmo rcarmo commented Sep 23, 2016

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

@slepkaviba slepkaviba commented Aug 12, 2017

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
Copy link

@escalonn escalonn commented Dec 8, 2017

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
Copy link
Author

@rcarmo rcarmo commented Dec 9, 2017

@texasbruce
Copy link

@texasbruce texasbruce commented Jun 25, 2018

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
Copy link
Author

@rcarmo rcarmo commented Jun 25, 2018

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
Copy link
Member

@joaomoreno joaomoreno commented Sep 17, 2018

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
Copy link

@DraconPern DraconPern commented Sep 26, 2018

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
Copy link

@alignedfibers alignedfibers commented Oct 23, 2018

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
Copy link

@nukata nukata commented Jan 4, 2019

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
Copy link

@Omir85 Omir85 commented Aug 23, 2019

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
Copy link

@AnrDaemon AnrDaemon commented Sep 9, 2019

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
Copy link

@texasbruce texasbruce commented Sep 9, 2019

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
Copy link

@AnrDaemon AnrDaemon commented Sep 9, 2019

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
Copy link

@texasbruce texasbruce commented Sep 9, 2019

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
Copy link

@AnrDaemon AnrDaemon commented Sep 9, 2019

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
Copy link

@AnrDaemon AnrDaemon commented Sep 9, 2019

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
Copy link

@AnrDaemon AnrDaemon commented Sep 10, 2019

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
Copy link

@igordcard igordcard commented Sep 17, 2019

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

@lalawue
Copy link

@lalawue lalawue commented Jan 25, 2020

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
Copy link

@dmak dmak commented Jan 7, 2021

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 git "${argv[@]}"
fi
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet