On Sun, Apr 21, 2013 at 11:01:58AM -0700, Junio C Hamano wrote:
> > 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.
> At least for a string whose "host" part does not have any slash,
> switching the rules 2 and 3 in git_connect() would be a regression,
> no? "frotz:/srv/git/git.git" has been the way to talk to host frotz
> for a long time, and if you want to talk to a local directory that
> is a subdirectory of "frotz:/" directory you have in your $cwd, you
> can disambiguate by saying "./frotz:/srv/git/git.git" or something.
Yeah, it would be a regression for fetch, though "git clone frotz:/srv"
is already broken if that file exists; it turns into `realpath
frotz:/srv` before we even feed it into the fetch machinery.
So I think one reasonable path would be:
1. Do not treat "host:path" as ssh if "host" has a slash, which should
not regress anybody. It does not allow unadorned relative paths
with colons, but it lets you use absolute paths or "./" to
2. Teach git-clone to ask the transport code to parse the source repo
spec, and decide from that whether it is local or not. That would
harmonize the implementations and avoid errors when you _did_ mean
to use ssh, but "host:path" happens to exist in your filesystem. I
also would not be surprised if there are problems with
URL-encoding, but maybe clone handles that properly (I didn't
And the "host contains slash" rule is pretty easy to explain in the
documentation, which is good.
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