The documentation says plain as day that VSCode does not come with git, that it leverages your machine's git installation and you must install it.
HOWEVER, it worked just fine for me. I only had github desktop and I am absolutely positively sure that I did not have git for windows installed and github desktop did not place itself in my PATH. (Technically I did have git on Bash on WSL but I know vscode isn't/can't access that). And yet it worked just fine for the longest time.
So, my question is, did vscode come with its own git executable? I ask because ever since I set up 2 factor auth on my github account I've been having to manually log in each time I push, it doesn't use my SSH keys stored in username/.ssh like git shell does.
Github Desktop installs git for you, typically located "C:\Program Files\Git", which is what VSCode, in your case, is most likely using.
If you refer to the answer from this post:
VSCode Terminal + Git Bash "command not found" for any command
it shows the settings (settings.json) that you need to add to allow for git bash and login to be used.
Hopefully this helps!
Related
I am using a setup on Windows 10 x64 where I install and manage git via scoop, rather downloading and executing the installer myself. Via the PowerShell, I ran
scoop install git
scoop install openssh
[environment]::setenvironmentvariable('GIT_SSH', (resolve-path (scoop which ssh)), 'USER')
However, now when I try to run commands in the Git Bash like
git clone git#example.org:vendor/repository.git
or a simple
git push/pull
I only get
CreateProcessW failed error:193
ssh_askpass: posix_spawn: Unknown error
instead of the Git Bash asking me for my SSH key's passphrase.
I am using the same setup (git installed via scoop) on many other Windows 10 x64 and no problems occur there. So I am not sure what is going wrong on this one. I previously had git installed without scoop on the same machine and the Git Bash was working fine. I uninstalled git completely (and also restarted the machine, just to be sure) before re-installing it via scoop instead.
The SSH_ASKPASS environment variable contains the following, in case this is relevant:
$ echo ${SSH_ASKPASS}
/mingw64/libexec/git-core/git-gui--askpass
Not sure what that folder refers to (something internal to the Git Bash presumably?), since it obviously does not exist like that on my machine.
Update
When using git-with-openssh instead of just git and openssh separately it works. However, I don't use that on my other machines, so I'd still like to know why it's not working here.
I'm pretty sure my answer does not address the OP's original case. But as of 2020, there seems to be a similar issue with a different way of solving it, and that's how I did in my case.
Part of the problem is, now Windows 10 has its own version of OpenSSH available, and at least in the case of my work's machine it seems that option is enabled by default.
This bundled OpenSSH is not compatible with Git bash though, so if you wants to use it, you must force git use scoop's provided OpenSSH (either from openssh or git-with-openssh packages). That means overwriting GIT_SSH environment variable, e.g. by adding a line similar to this to your .bashrc:
export GIT_SSH='C:\Users\rogs\scoop\apps\git-with-openssh\current\usr\bin\ssh.exe'
Hope it helps.
Even if this topic is already very old, the problem persists. I found out that its enough to simply unset the environment variable to get rid of this error.
unset SSH_ASKPASS
Just put this in your .bash_profile and/or your .bashrc.
Indeed I have same issue which is mentioned here "Why does bash (from git installation) give me segmentation fault suddenly?
"
My git was working properly. But I need to regenerate keygen value and I got segmentation fault. I remoted git and installed the latest version of git (2.19.0-64-bit). I tried with git-bash from search, bash.exe from bin folder , git.exe from bin folder , git-bash.exe under Git Folder and git-cmd.exe under Git folder. The results are same.
After I read the link I shared above , I checked the windows updates as well. But there is no update.
Is there any idea ? Thanks in advance
2.9 is not the latest, one: 2.19 is.
Try (for testing) and uncompress the latest Git for Windows portable archive PortableGit-2.19.0-64-bit.7z.exe anywhere you want.
Then setup a simplified path in a CMD session.
set PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
set GIT_HOME=C:\Path\to\Git
set PATH=%GIT_HOME%;%GIT_HOME%\bin;%GIT_HOME%\usr\bin;%GIT_HOME%\mingw64\bin;%PATH%
(Add any other path you would need)
Try then to regenerate your SSH key.
Also, make sure this is not related to an AV (Anti-Virus) as in issue 1832 or issue 1291.
My company also uses TrendMicro.
Can confirm that making an exception for /Git/usr/bin/bash.exe works as well.
For me it was C:\Program Files\Git\usr\bin, but adding it to the list of trusted programs did indeed fix the issue
I faced the same problem yesterday. Using git-bash, all my commands (i.e. mvn, javac, git pull) were giving error "Segmentation fault". This was because an update of my machine anti-virus which blocks proper access to my local login profile (sambit-swain#TERMINAL) After un-installing it, everything went back to normal.
So, the problem is not with GIT BASH or any other configuration. I should have checked the access levels (including SSH keys) to programs.
There are many fine instructions about how to work with git under windows using GitBash.
I note that when git is installed, it offers the option of "set up for using git from the windows prompt", which puts git on the windows path.
Is there some way to set this up so that ssh authentication works?
At the moment I get "permission denied (publickey)" when I try to do git commands that access the remote.
(edit) I have set %HOME% to point to my Windows home directory, and there is a .ssh folder in there with id files that work under a gitbash shell.
I appreciate that the answer is likely "no, this is why GitBash exists". But - it would be good to know for sure.
If the answer is "no" it kinda makes you wonder why you would bother putting git on your windows path?
ssh access works fine from a regular DOS session.
You only need to define C:\Users\YourAccount\.ssh and add your id_rsa and id_rsa.pub there.
Launch your git session through git-cmd.bat, which will define %HOME% to your C:\Users\YourAccount: that is what will make ssh work.
This should put your msysgit/bin installation in your PATH.
I really recommend not installing through a msi (Microsoft Installer), but through a simple unzip of an archive (portable version "PortableGit-x.y.z-preview201ymmdd.7z")
And the OP GreenAsJade's comment points out the fact that GIT_SSH must point to plink.exe.
Well, maybe I have a process that seems to work.
If you use a passphrase during the generation of the keys, you'll have to type this passphrase after loading an ssh-agent and add the key to the agent.
Basically, the solution is: follow the instructions on this page:
https://confluence.atlassian.com/bitbucket/set-up-ssh-for-git-728138079.html
BUT, during the generation of the keys DO NOT TYPE A PASSPHRASE.
Obviously, it's 'weaker' from a security point of view.
But, the .bashrc script will work as expected (loading the identity on git bash startup).
You can use then the "start-ssh-agent.cmd" script located on Git\cmd folder. It will open a Dos Prompt with the identity loaded and everything will work!
I am really enjoying my time with git.
I'm operating on 2 machines with what I thought were pretty similar setups
On my Laptop
When I type "Git help SomeCommand" from the CLI, my laptop launches the html help in my browser and I am free to read up on whatever help element I asked about.
On my Desktop
The CLI responds as if is is going to do the same, but no browser is switched to and no help is launched
What can I do to get my help back on my desktop?
Note: I'm running the bash shell through console2, but this problem appears to affect the default bash shell run via the context menu in explorer just as much.
I just recently had the same problem, browser wouldn't launch.
I'm running Git 1.9.2.msysgit.0 on Windows 8.1. Default browser - Chrome.
None of the solutions above worked for me. But I simply went to the html file in the explorer, and double-clicked it. Windows then asked me what app to use to open it, and I chose chrome.
Now usual git commands work and open the help html files in Chrome.
As mentioned in the msysgit bug report 445:
Git has it's own tool called "git web--browse" that invokes the web-browser.
Set the environment GIT_TRACE to 1 to see what processes are started, and with what
command-lines.
So that can help debugging the issue.
A temporary workaround (which might not be effective in your case) was:
As temporary workaround one can rename all git-<command>.html to git<command>.html in his <Git>\doc\git\html directory.
The git <cmd> --help suggested by Andy seems to have helped though, and must have "reset" something.
You can configure a web browser to be used to open Git's help files independently of the system's default program assigned to open .html files.
To check if it's set and to what value, simply run:
git config web.browser
To set it globally for all repositories, for example to chrome, run:
git config --global web.browser chrome
You can also set it per-repository, in that case run it inside a repository and without the --global parameter:
git config web.browser chrome
It works automatically if the specified browser's executable is in PATH. If it's not, you may set it manually:
git config browser.<name>.path <path-to-browser-executable>
...so for Chrome browser, it may look like the following:
git config browser.chrome.path "c:\Program Files (x86)\Google\Chrome\Application\chrome.exe"
See the documentation for details.
It seems that this bug went away when I upgraded to the latest version of msysgit (1.7.6 from 1.7.3)
I have this problem currently, and the git <cmd> --help technique doesn't fix it.
I have however found that doing
git help -w <cmd>
Will actually open the help file in the browser, so this is a useful workaround.
I had the same problem (browser wouldn't open), then I realized it's probably because our laptops at work are "least privileged access", meaning we're logged into our Windows systems as standard users. But for development work, including the command window I'm doing git commands from, I'm running as a different user who has local admin privileges. So it actually was opening the Chrome browser, just not in my "logged in" desktop session where I could see it.
To work around this, I ran another copy of Chrome as that user (by Shift-Right clicking on Chrome.exe and running it as the same privileged user that my command prompt is running as). Once that instance of Chrome was running on my desktop, I returned to the command prompt and re-ran the "git help " and it properly launched a new tab in that instance of the browser that was running as the same user my command prompt was.
Stab in the dark: I've always done git <cmd> --help. Does that work?
edit: For future reference. This appears to be what fixed the OP's problem. Running git <cmd> --help seemed to have cleared out something so that it works as specified now. If only I knew the how/why of it...
This set up is current, working and the convention.
It's most likely because you are using the default Git that comes with MacOS called Apple Git which is outdated.
run git --version and check against the Git website.
Install Git using brew install git.
To make sure Homebrew installs take precedence over MacOS installs add the usr/local/bin path to your .zshrc or .bash_profile. export PATH=/usr/local/bin:$PATH. (*Btw, you should use this path also for using Python 3 instead of MacOS Python 2.7 and many other applications).
To make sure all of this is activated do source ~/.zshrc or source ~/.bash_profile. Or simply restart Terminal.
Test it. git help -w commit. A browser window will open.
I'm having trouble getting post-recieve and post-commit hooks to work correctly with msysgit (Windows 7 Pro/32 and Ultimate/64). For post-commit hook I get the above error if I commit from either git-bash or the console, but it works fine if I commit through git-gui. For a post-recieve hook, all three give the same error.
I'm thinking this is some sort of permission or path error, but don't really have any clue where to start here.
Add the SHEBANG to the first line of hook, like so:
#!/bin/sh
echo "executing post-commit"
exit 0
This had me stumped for a while as well and I saw that adding the shebang fixed it. In SVN world, while in *nix we have a "pre-commit" script and in Windows we had "pre-commit.bat" and SVN automatically picked up the bat file in Windows. Git doesn't seem to pick up a pre-commit.bat ( or any hook ) and adding the shebang to the hook file worked.
I'm using SourceTree and git LFS and had a similar issue: cannot spawn .git/hooks/pre-push.
The fix was to delete the pre-push file (opening it revealed it was badly corrupted) and restart SourceTree at which point it regenerates the pre-push file and everything is back to normal.
If you have the SHEBANG and it still fails, make sure you have <path_to_git>\bin set in your path environment variable.
You'll probably also have <path_to_git>\cmd if you installed it to work from the command-line.
This is an old question, but I've been fighting with this exact problem and this SO question popped up, so I thought it worth the effort to record what worked for me.
In short: I needed to run Apache as a regular user instead of Local System. This was on a legacy test VM I was playing with, so it was only running Windows XP, but it appears that at least on that platform (and possibly others), msysgit just doesn't work properly when running under the Local System account (presumably the root filesystem isn't mapped properly). As a result, no shebang line will work as git-http-backend simply can't execute any msysgit binaries (even with absolute Windows paths).
Switching Apache to run as a regular user account fixed this problem completely. Obviously you need to ensure that the user Apache is running as has permissions to read/write the git repositories, but beyond that, just make sure your shebang line is #!/bin/sh and everything should be copacetic.
Lastly, yeah, this is a big hammer. Ideally you'd be able to use something like suexec on Windows, but a quick googling doesn't indicate an obvious path forward, there. Of course, if anyone has any ideas, I'd be interested.
For now, this works for me, but it doesn't seem ideal.
Got this in a repo using LFS, got rid of it with git lfs update --force
If someone, like me run into a similar problem with accessing git repositories through apache, you should set the PATH in Apache config, like:
SetEnv PATH "c:/Program Files (x86)/Git/bin;"
Using tortoisegit and LFS, for me just had to remove the files inside of the .git/hooks folder.
If you are using Android studio, you can remove this error by un-check the checkbox "Run Git hooks":
For me, removing a comment line on front of the shebang line fixed the error. Oddly, the script ran fine from the shell, just errored out when run as a hook.