Re: [BUG] Filenames with single colon being treated as remote repository

From: Jeff King <peff@peff.net>
Date: Apr 21, 2013, 12:45 UTC
Message-ID: <20130421124511.GA1933@sigill.intra.peff.net>
In-Reply-To: <20130421060538.GB10429@elie.Belkin>

On Sat, Apr 20, 2013 at 11:05:39PM -0700, Jonathan Nieder wrote:

Show 12 quoted lines

> >     Cloning into 'new-baz'...
> >     ssh: Could not resolve hostname /tmp/foo: Success
> >     fatal: Could not read from remote repository.
> 
> Here's a toy patch.  I haven't thought carefully about whether it's a
> good idea, but maybe it can be useful for thinking about that.
> 
> Still needs documentation and tests.
> 
> My main worry is that the proposed rule for when an argument is
> treated as a local path is hard to explain.  There's some precedent in
> handling of bundles, though.  What do you think?

I think the rule could be something like:

  1. If it looks like a URL ("^scheme://"), it is.

  2. Otherwise, if it is a path in the filesystem, it is.

  3. Otherwise, if it has a colon, it's host:path

  4. Otherwise, barf.

where the interesting bit is the ordering of 2 and 3. It seems like "git clone" follows the order above with get_repo_path. But we do not seem to follow it in git_connect, where we prefer 3 over 2.

Show 8 quoted lines

> @@ -942,6 +943,7 @@ struct transport *transport_get(struct remote *remote, const char *url)
>  		ret->disconnect = close_bundle;
>  		ret->smart_options = NULL;
>  	} else if (!is_url(url)
> +		|| (is_local(url) && !stat(url, &st))
>  		|| !prefixcmp(url, "file://")
>  		|| !prefixcmp(url, "git://")
>  		|| !prefixcmp(url, "ssh://")

I don't think that is enough. Something like /path/to/foo:bar would trigger !is_url already, but then git_connect fails.

Try:

  $ git init --bare foo:bar
  $ git clone foo:bar
  ssh: Could not resolve hostname /home/peff/foo: Name or service not known
  fatal: Could not read from remote repository.
  ...

Clone recognizes it as a path and turns it into an absolute path. It then feeds it to the transport code, which triggers !is_url and knows to use the git transport. But then git_connect prefers ssh over the filesystem.

If you do a straight fetch, though, the transport code might see the relative path (if you use one):

  $ git init
  $ git init --bare sub:repo
  $ git fetch sub:repo
  ssh: Could not resolve hostname sub: Name or service not known

but that still triggers the is_url above (which demands the "://").

I am not sure whether your patch covers any cases I am missing, but I think you would need an analogous change to git_connect for these common cases.

-Peff