Jeff King <p...@peff.net> writes: > 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.
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. -- 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