Re: URL Syntax Question

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 1, 2008, 06:11 UTC
Message-ID: <7vej9qgl44.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <E1JgUp6-0002Sc-Ts@jdl.com>

Jon Loeliger <jdl@jdl.com> writes:

Show 17 quoted lines

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