Re: URL Syntax Question

[Junio C Hamano <gitster@pobox.com>]

Jon Loeliger <jdl@jdl.com> writes:

> On, for example, the git-clone man page, the stated URLs
> that are supported include these:
>
>     git://host.xz/path/to/repo.git/
>     git://host.xz/~user/path/to/repo.git/
> and:
>     ssh://[user@]host.xz[:port]/path/to/repo.git/
>     ssh://[user@]host.xz/path/to/repo.git/
>     ssh://[user@]host.xz/~user/path/to/repo.git/
>     ssh://[user@]host.xz/~/path/to/repo.git
> and:
>     rsync://host.xz/path/to/repo.git/
>
> In the first set, is the non-specified user form also supported?
> That is, this form:
>
>     git://host.xz/~/path/to/repo.git/

Because git-daemon protocol does not authenticate, ~/ cannot mean "home
for connecting user".  It appears that the "user_path" modification made
long time ago to daemon.c in 603968d (daemon: extend user-relative path
notation., 2006-02-04) was sloppily done and does not check and error out
for this case, but I think it should.

The ~user syntax depends on the daemon side running with --user-path
option; otherwise it won't be accepted.

> In the second set, is it fair to generalize and say
> that they could all be respresented as this:
>
>     ssh://[user1@]host.xz[:port]/[~[user2]/]path/to/repo.git/

We interpret [:port] part in order to add "-p port" parameter to the
command line we invoke "ssh" with; "[user1@]host.xz" part is handled by
the underlying "ssh".

The command line we pass to the "ssh" to run on the remote side is either
"upload-pack /path/to/repo.git" or "upload-pack ~[user2]/path/to/repo.git/";
I suspect how it is handled depends on the shell that run on the remote
end.

Personally, I'd prefer the scp syntax, which tends to be shorter and
sweeter, though:

	host.xz:path/in/my/home/directory/repo.git
        host.xz:/absolute/path/to/repo.git

> Lastly, how long before the deprecated and third class citizen,
> rsync, is actually _removed_?  Or will it linger for all time?
> Any plans in the works there?

I haven't heard of any concrete plans, but it might not be a bad idea to
declare for removal at 2.0.0.  rsync is really the last-ditch protocol,
and even after we stop supporting it natively, the user can still:

	cp -lr repo.git local-copy.git ;# prime with what we have
	rsync -r host.xz/path/to/repo.git local-copy.git

and then use the local-copy.git as if it is the remote one.