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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html