git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [EGIT PATCH 1/3] Give NoRemoteRepositoryException better message in BasePackConnection

From
Shawn O. Pearce <spearce@spearce.org>
Date
Aug 28, 2008, 02:44 UTC
Message-ID
<20080828024437.GD8624@spearce.org>
In-Reply-To
<48B61016.7050401@gmail.com>
Marek Zawirski <marek.zawirski@gmail.com> wrote:
Show 28 quoted lines
> Shawn O. Pearce wrote:
> (...)
>> +	@Override
>> +	protected TransportException noRepository() {
>> +		// Sadly we cannot tell the "invalid URI" case from "push not allowed".
>> +		// Opening a fetch connection can help us tell the difference, as any
>> +		// useful repository is going to support fetch if it also would allow
>> +		// push. So if fetch throws NoRemoteRepositoryException we know the
>> +		// URI is wrong. Otherwise we can correctly state push isn't allowed
>> +		// as the fetch connection opened successfully.
>> +		//
>> +		try {
>> +			transport.openFetch().close();
>> +		} catch (NotSupportedException e) {
>> +			// Fall through.
>> +		} catch (NoRemoteRepositoryException e) {
>> +			// Fetch concluded the repository doesn't exist.
>> +			//
>> +			return e;
>> +		} catch (TransportException e) {
>> +			// Fall through.
>> +		}
>> +		return new TransportException(uri, "push not permitted");
>> +	}
>> +
>
> Nice idea, even if it's crazy and time-consuming, it's probably better  
> than my previous one.
I'm not too worried about the extra time used here.

This happens only after we have already opened a connection and received no refs at all from the remote peer. So the user has already had to wait to get this far.

By asking the same transport to open the fetch we can reuse an existing SSH tunnel for the new command if this is an SSH connection, so the setup costs are a lot lower then the original connection.

We are already in a bad error condition; we cannot continue and the user is about to get an error. I would rather give them the best error message we can determine than abort early and give them something misleading.

-- 
Shawn.
Previous: Marek Zawirski
Message 10 of 10 in “Give NoRemoteRepositoryException better message in BasePackConnection”
  1. 1/3 Give NoRemoteRepositoryException better message in BasePackConnectionMarek Zawirski, Aug 28, 2008
  2. 2/3 Handle NoRemoteRepositoryException in PushOperation especiallyMarek Zawirski, Aug 28, 2008
  3. 3/3 Show ErrorDialog fot fatal connection errors in ConfirmationPageMarek Zawirski, Aug 28, 2008
  4. Shawn O. PearceAug 28, 2008
  5. Marek ZawirskiAug 28, 2008
  6. Shawn O. PearceAug 28, 2008
  7. Marek ZawirskiAug 28, 2008
  8. Shawn O. PearceAug 28, 2008
  9. Marek ZawirskiAug 28, 2008
  10. Shawn O. PearceAug 28, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.