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

From: Jeff King <peff@peff.net>
Date: Apr 22, 2013, 15:35 UTC
Message-ID: <20130422153516.GB11886@sigill.intra.peff.net>
In-Reply-To: <7vd2tnvk2x.fsf@alter.siamese.dyndns.org>

On Sun, Apr 21, 2013 at 11:01:58AM -0700, Junio C Hamano wrote:

Show 20 quoted lines

> > 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
     disambiguate.

  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
     check).

And the "host contains slash" rule is pretty easy to explain in the documentation, which is good.

-Peff