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

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