I upgraded my OS to Windows 7 and installed mercurial, but I can't seem to be able to clone any remote repository. Windows Firewall is disabled and I don't have a third-party firewall. I even tried to launch the command prompt as administrator. No matter what I do, I always get this Operation timed out error. Any ideas?
c:\Users\Alfred>hg clone http://bitbucket.org/jespern/django-piston/ hgrepo
abort: error: Operation timed out
Hrm, what does the output look like when you include --debug and --verbose?
Also, what happens if you clone over ssh using this command line?
hg clone ssh://hg#bitbucket.org/jespern/django-piston/ hgrepo
It works fine when I clone it just now. I guess Bitbucket simply had a small problem. In such a case, the best reaction is to log onto the #bitbucket IRC channel on irc.freenode.net -- StackOverflow is not a very good support forum, especially for transient problems like this.
Related
I'm attempting to use PHPStorm's built-in VCS functionality on a windows machine. When I set it up to utilize svn+ssh, I get the following error:
Problems while loading file history: svn: E170012: Unable to connect to a repository at URL 'svn+ssh://user#svr/repo_path/trunk'
svn: E170012: Can't create tunnel
svn: E720087: Can't create tunnel: The parameter is incorrect.
The repository information is correct and I don't have any issues connecting via TortoiseSVN. I've attempted to configure it utilizing both TortoisePlink.exe and putty's plink.exe. I've used both Pageant and tried to provide the key at the command line.
I normally work with OS X and Linux environments, but that's not an option in this case and I'm not exactly sure what to check next and I'm not finding a lot online via google search. Any suggestions would be greatly appreciated.
I ran into the same issue and found this path to the solution: How to use svn+ssh with Tortoise SVN from the command line
In context of PhpStorm:
PhpStorm discontinued using SVNKit with svn >= 1.8 so it will not ask for your SSH credentials anymore as it did before but will depend on proper command-line clients to be available and configured.
Now, this works for me:
Load your private key with Putty pageant (double click on key and enter your password)
Add a SVN_SSH Windows environment variable with content: C:\\Program Files\\TortoiseSVN\\bin\\TortoisePlink.exe (Adjust to your path, but keep the double backslashes!)
Now, from the command line (restart command line window before trying)
echo %SVN_SSH% needs to give you the plink.exe path and you should be able to do a svn up on command line without entering your password.
Restart your PhpStorm and SVN should work.
I've spent quite time on the issue, yet still couldn't find the exact problem. One issue is about the 1.8 format of SVN with PhpStorm, it cannot handle the svn+ssh authentication. It is possible to use TortoiseSVN 1.8 but always sticking the 1.7 format in PhpStorm.
My final solution was to install TortoiseSVN 1.7, so that I can use it from the Windows menu as well and no formatting issues happen. Another setting necessary for me was unchecking the option under Version Control > Subversion.
[] Use command line client: svn
As the ssh executable, I use:
C:\Program Files (x86)\PuTTY\plink.exe
Getting this error when setting up my GitHub repo in Jenkins on a OS X machine.
Failed to connect to repository : Command "git ls-remote -h https://github.com/username/repo.git HEAD" returned status code 128:
stdout:
stderr: fatal: unable to access 'https://github.com/username/repo.git/': Internal SSL engine error encountered during the SSL handshake
This has been working before and I've been running build successfully connected to this repo but all of a sudden I started to get this message. Does anybody have any idea?
Thanks
PS. Have looked at the other related questions but they don't have the exact same issue and/or are not on the same platform as me.
I think I found what the issue was. I logged into the mac machine with a certain user and started the jenkins.war file from there. It worked fine until I logged out the user, that's when I started to see the problem and why I resolved it by restarting the computer. So as long as I am not logging out the jenkins user, everything is fine.
Original question
From a few hours of struggling with installing git on Windows 7. First I installed the GitHub on Windows but not appealed to me. Then I installed the Git-1.9.2-preview20140411 and have started to have problems.
I suppose that there is a conflict by multiple installations. So I uninstalled everything. I decided to try Cygwin.
I acted according to this tutorial: How To install Git client on Windows using Cygwin By Johnathan Mark Smith
I added the generated public key SSH to my account on GittHub by Web browser . I created the first repository (through a browser).
After returning to the cygwin terminal and I typed:
git clone git#github.com:akawalko/ZFExt.git
I received such a result
Cloning into 'ZFExt'...
ssh: Could not resolve hostname github.com: Non-recoverable failure in name resolution
fatal: The remote end hung up unexpectedly
I do not understand this message. I did something wrong?
EDIT 1:
To the person who gave me the minus one. In your opinion I shouldn't have asked. Instead, format the hard drive. In this way it would be okay?
Updated question
I started to ask google with less detailed questions and i found it: git and ssh: Could not resolve hostname, ping works. I changed my DNS addresses to open DNS and was able to clone my repo by using ip adres instead domain:
git clone git#192.30.252.128:akawalko/ZFExt.git some_git_repo/
Using domain name still not work:
git clone git#github.com:akawalko/ZFExt.git some_git_repo/
Cloning into 'some_git_repo'...
ssh: Could not resolve hostname github.com: Non-recoverable failure in name resolution
fatal: The remote end hung up unexpectedly
Any ideas (other then changing DNS)?
I had this issue inside a VMware Fusion VM. I had to change my network from NAT to Bridged and it started working.
For anyone else having this issue on VMWare Fusion and Windows 10, see this thread: https://communities.vmware.com/thread/518949?start=0&tstart=0
In summary, ssh won't do dns resolution over NAT on Fusion with Windows 10. This is a known bug, but in the meantime, add an entry to your host file to access bitbucket
131.103.20.167 bitbucket.org
Also, as #Jim Redmond pointed out, bitbucket is changing their IP addresses soon (December 15, 2016).
Another, more permanent, option would be to set Google as your DNS provider. Use 8.8.8.8 or 8.8.4.4. Or for ipv6: 2001:4860:4860::8888 or 2001:4860:4860::8844. https://developers.google.com/speed/public-dns/docs/using
For me, it started happening when I upgraded to Git 2.7.4. The fix in the link below worked for me, you need to change SSH configuration in \etc\ssh\ssh_config.
AddressFamily inet
See the last comment in the thread linked below:
Can't resolve hostname with SSH
Summary
It's been a few days and I have not found any solution. In conclusion, it's more a problem with the operating system than the tools (Cygwin, Git).
I installed two competing Git clients (Git-1.9.2-preview20140411 and GitHub on Windows) which resulting in messed up windows registry. This gives in an error: STATUS_ACCESS_VIOLATION at eip=68086014. I returned to app GitHub For Windows and will use Windows Power Shell. It's far from perfect but it works.
I was so focused on problem mentioned above that I didn't spot problem with DNS. Because I don't have knowledge how to solve this problem (answers on stackoverflow didn't work for me) I will use the IP address instead of github domain in commands like git clone and others until I reinstall Windows. :-(
I have modified the title to more precise.
Big thanks to #Chris for his contribution.
I had the same problem .then I tried with account name prefixed in the domain.
like try
git clone git#youraccountname.github.com:akawalko/ZFExt.git
it worked for me also make sure in your git config you are using the same url.
Experienced the same problem with Windows 7 and VmWare Fusion 8.5.3.
Tried 2 options. Both worked. But issue is weird. Seem to happen to github.com and bitbucket.com only.
Setting DNS manually in adapter settings (e.g. 8.8.8.8)
Change networking from NAT to Bridged
For me it works fine when I changed the hostname to ip address.
I'm using Jenkins on Win7 and i've installed tomcat for ssh-agent plugin. And I could clone my GitLab project via git bash via ssh.
But if I build the project by Jenkins, it always says :
[ssh-agent] Using credentials IliptonChen(APRTest)
[ssh-agent] Looking for ssh-agent implementation...
[ssh-agent] FATAL: Could not find a suitable ssh-agent provider
FATAL:[ssh-agent] Unable to start agent
The full output text is here
Did I do anything wrong?
Check the version of your ssh-agent used by Jenkins.
This bug (for linux, but could apply to Windows too) reports (10 days ago, January 2014) this very same error message:
"JENKINS-20276: Native Library Error after upgrading ssh-agent from 1.3 to 1.4".
Downgrading to 1.3 resolves the issue.
Update 2019, five years later: as commented, this should be fixed now.
ssh-agent.exe is part of a Git for Windows distribution
D:\git\git>where ssh-agent.exe
D:\prgs\gits\current\usr\bin\ssh-agent.exe
(provided path/to/git/usr/bin is first in the %PATH% used by Jenkins)
Assuming you've installed Windows Git on Windows slave, it comes with ssh-agent binary (e.g. C:\Program Files\Git\usr\bin). Try adding its path to system variable PATH.
Otherwise untick SSH Agent and choose the credentials by selecting Credentials from dropdown in Source Code Management section.
Another way is to generate personal API token (OAuth) for that GitHub user and include that along with your repository address, e.g.
git clone https://4UTHT0KEN#github.com/foo/bar
For windows, the plugin still requires Tomcat to be installed in both master and slave.
I got this error because I was using an Ubuntu image for the agent, which doesn't have SSH installed.
agent {
docker { image 'ubuntu:focal' }
}
... so the solution was as simple as installing SSH as part of the pipeline:
steps {
sh "apt-get update && apt-get install ssh -y"
// rest of your steps here...
}
In my case, the error was accompanied by an error about disk space depletion:
[ssh-agent] FATAL: Could not find a suitable ssh-agent provider
[ssh-agent] Diagnostic report
[ssh-agent] * Exec ssh-agent (binary ssh-agent on a remote machine)
[ssh-agent] hudson.AbortException: Failed to run ssh-agent: mkdtemp: private socket dir: No space left on device
So I ran docker system prune -a, which fixed it.
I've read several other 'git hangs on clone' questions, but none match my environment and details. I'm using git built under cygwin (msys git is not an option) to clone a repo from a Linux host over SSH.
git clone user#host:repo
I've tested against the same host on other platforms, and it works fine, but on this Windows machine the clone hangs indefinitely. I set GIT_TRACE=1 and it looks like the problem is with this command:
'ssh' 'user#host' 'git-upload-pack '\''repo'\'''
My SSH keys are set up correctly: ssh user#host works fine. When I run the command, I get a bunch of output that ends like this:
...
003dbbd3db63763922ad75bbeefa3811dce001576851 refs/tags/start
0000
Then it hangs for 20+ minutes, which is the longest I've waited before killing it.
The server has Git 1.7.11.7 with OpenSSH 5.9p1, while the client has Git 1.7.9 with OpenSSH 6.1p1.
Is that supposed to be the end of the git-upload-pack output? Is this a bug in Git or my configuration?
The upcoming git1.8.5 (Q4 2013) will document more the smart http protocol.
See commit 4c6fffe2ae3642fa4576c704e2eb443de1d0f8a1 by Shawn O. Pearce.
With that detailed documentation, the idea would be to monitor the web requests done between your git client and the server, and see if those conforms to what is documented below.
That could help in pinpointing where the service "hangs".
The file Documentation/technical/http-protocol.txt insists on:
the "Smart Service git-upload-pack"
Clients MUST first perform ref discovery with '$GIT_URL/info/refs?service=git-upload-pack'.
C: POST $GIT_URL/git-upload-pack HTTP/1.0
S: 200 OK
S: Content-Type: application/x-git-upload-pack-result
S: Cache-Control: no-cache
S:
S: ....ACK %s, continue
S: ....NAK
Clients MUST NOT reuse or revalidate a cached reponse.
Servers MUST include sufficient Cache-Control headers
to prevent caching of the response.
Servers SHOULD support all capabilities defined here.
Clients MUST send at least one 'want' command in the request body.
Clients MUST NOT reference an id in a 'want' command which did not appear in the response obtained through ref discovery unless the server advertises capability "allow-tip-sha1-in-want".
The "negociation" algorithm
(c) Send one $GIT_URL/git-upload-pack request:
C: 0032want <WANT #1>...............................
This worked for me, incase it helps someone else.
Check your git remote url. It might hang with git-upload-pack on a trace if your using the wrong url type. You change the url from ssh git#github.com: to https://github.com/ on your remote.
We have faced a similar issue - and we attributed it to the following: Our git repo has a LOT of binary files checked in (multiple versions, over the past 1.5 years of this project). So, we assumed that this was the cause.
To support this theory, we have other code bases that are more recent (and thus do not have so many binary files and their versions) - which do not exhibit this behavior.
Our setup: Git setup on linux, site-to-site VPN between London and India over a T1 line.
I was having this same problem after I added some jazz like this to my ssh config in order to set window titles in tmux:
Host *
PermitLocalCommand yes
LocalCommand if [[ $TERM == screen* ]]; then printf "\033k%h\033\\"; fi
getting rid of that fixed my git.
An outdated PuTTy can also cause this. Your system might be using plink.exe as GIT_SSH.
You can install the latest development build from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html to make sure this is not the problem.
My problem was simple. I updated the VPN client and git started hanging. I quit the VPN client and restarted it.