On Sat, Apr 20, 2013 at 11:05:39PM -0700, Jonathan Nieder wrote: > > 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. > @@ -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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html