| Summary: | "Can't connect to any URI:" error when attempting to push a change to a local file origin repository | ||
|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | Michael Maguire <eclipse> |
| Component: | UI | Assignee: | Mathias Kinzler <mathias.kinzler> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | eclipse, joaohbruni, mathias.kinzler, mendrel, michael.deardeuff, stefan.lay |
| Version: | unspecified | ||
| Target Milestone: | 0.9.0-M3 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Michael Maguire
Repros for me on OSX as well with Build id: 20090920-1017 This is a bug: the configuration does not contain a push URL, but a (fetch-) URL. In this case, the fetch URL should be used for pushing, but the wizard wrongly uses the list of push URLs, which is empty. The fix is minimal and already part of the "bleeding edge" build, but at the moment there is no fix planned for 0.8, so I can not say when this will be available for this release. You can work around this by adding as push URL the same URL that is configured as (fetch-) URL. To do so, edit the "config" file of your respository, typically found at <your repository's directory>/.git/config. You will find a section looking similar to the following (the "push"-entry may not be there): [remote "origin"] url = http://egit.eclipse.org/egit.git fetch = +refs/heads/master:refs/remotes/origin/master push = HEAD:refs/for/master Simply copy the line starting with "url =" and paste it, replacing "url" with "pushurl". The resulting section in the config file would look similar to [remote "origin"] url = http://egit.eclipse.org/egit.git fetch = +refs/heads/master:refs/remotes/origin/master push = HEAD:refs/for/master pushurl = http://egit.eclipse.org/egit.git After saving the file, the wizard should work again. *** Bug 317747 has been marked as a duplicate of this bug. *** Thank you! We had the same problem on Linux after upgrading Helios and 0.8.4. Another incarnation of this bug: When attempting to do a push from my local workspace to the master workspace on github using Configured Remote URI (configured to a git+ssh URI), I get a "Can't connect to any to any URI: transport error ... NullPointerException". When manually entering the Custom URI, a dialog appears asking my for my passphrase and it all works properly. I had a slightly different experience with this bug. When creating a "new remote", I checked only the "Configure Push" checkbox. After successfull configuration of the remote and its push settings (git+ssh), I tried to PUSH the repository contents using the "Configured remote repository". In the "Push Ref Specifications" dialog, I was not able to click in any of the controls. The buttons were not disabled (they were not greyed out), but clicking on them produced no results (nothing happened, as if they were disbaled). Also, clicking in the combos (selects) for Source, Destination, and Delete refs produced no results (just like the buttons, they behaved as if they were disabled). In short, the dialog was unusable, not responding to anything, so I was not able to finish the action. I found this blog post: http://blog.christophersmart.com/2010/07/05/eclipse-egit-push-bug-solved - it contains the workaround mentioned in this bug, to manually add the "pushurl" configuration. But when I opened my .git/config file, it contained the following (privacy note - I changed the URL domain and username below): [core] repositoryformatversion = 0 filemode = true logallrefupdates = true autocrlf = false [remote "GitRepo"] pushurl = git+ssh://git@user.example.com/user/example.git push = refs/heads/*:refs/heads/* push = refs/tags/*:refs/tags/* The "pushurl" was there! So, I decided to try adding an "url" setting, and added a line into the remote configuration (copied "pushurl" and renamed as "url"): [remote "GitRepo"] url = git+ssh://git@user.example.com/user/example.git pushurl = git+ssh://git@user.example.com/user/example.git push = refs/heads/*:refs/heads/* push = refs/tags/*:refs/tags/* For my surprise and satisfaction, it worked! I am reporting this experience here, because I am not aware if the "bleeding edge" build corrects this case also. Thanks! (In reply to comment #6) > I had a slightly different experience with this bug. > (snip) > > I am reporting this experience here, because I am not aware if the "bleeding > edge" build corrects this case also. > > Thanks! Thanks a lot for pointing this out. I have already come across this a while ago but am still waiting for another change to get in so I can fix this. Will fix this ASAP (in the bleeding edge build). Code review at http://egit.eclipse.org/r/#change,1413 The bug should be fixed by commit 58877c0d8df281566d259e57baf876acd8120eab |