Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 317389 - "Can't connect to any URI:" error when attempting to push a change to a local file origin repository
Summary: "Can't connect to any URI:" error when attempting to push a change to a local...
Status: RESOLVED FIXED
Alias: None
Product: EGit
Classification: Technology
Component: UI (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 0.9.0-M3   Edit
Assignee: Mathias Kinzler CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 317747 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-06-20 19:26 EDT by Michael Maguire CLA
Modified: 2010-09-07 10:58 EDT (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Maguire CLA 2010-06-20 19:26:23 EDT
Build Identifier: I20090611-1540

Eclipse EGit 0.8.4

I have a bare 'master' repository on a shared file server, and a local repository which I use as a working one.

When attempting to do a push from my local workspace Git repository to my 'master' Git repository (using file:///), the first dialog which pops up asks me to specify "Destination Git Repository".

This appears to be already (correctly) defaulted to "Configured remote repository:   origin: file:///C:/Users/Michael/Documents/MyRepository.git"

However if I then configure the sourcfe and dest ref and proceed, I get:

"Can't connect to any URI:"  (nothing else shown afterwards)

If I do the very same thing but instead at the first dialog manually re-enter a "Custom URI:" pointed at the very same file:///C:/Users/Michael/Documents/MyRepository.git file, everything works.



Reproducible: Always

Steps to Reproduce:
1. Import a local repo from a file:/// bare master repo
2. Attempt to push changes from local to master
3. Use the default "Configured remote repository:"
Comment 1 Michael Maguire CLA 2010-06-20 19:33:10 EDT
Repros for me on OSX as well with Build id: 20090920-1017
Comment 2 Mathias Kinzler CLA 2010-06-29 11:42:42 EDT
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.
Comment 3 Mathias Kinzler CLA 2010-06-29 11:43:45 EDT
*** Bug 317747 has been marked as a duplicate of this bug. ***
Comment 4 Chris Smart CLA 2010-07-05 02:47:47 EDT
Thank you! We had the same problem on Linux after upgrading Helios and 0.8.4.
Comment 5 michael.deardeuff CLA 2010-07-15 03:51:31 EDT
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.
Comment 6 J Bruni CLA 2010-07-31 08:16:32 EDT
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!
Comment 7 Mathias Kinzler CLA 2010-08-06 08:41:20 EDT
(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).
Comment 8 Mathias Kinzler CLA 2010-08-25 08:10:15 EDT
Code review at http://egit.eclipse.org/r/#change,1413
Comment 9 Stefan Lay CLA 2010-09-07 10:58:55 EDT
The bug should be fixed by commit 58877c0d8df281566d259e57baf876acd8120eab