Unable to get "pretty" URL aliases working

Hi all,

I'm attemping to learn Git but I've gotten stuck trying to configure a server to host my repositories.

I would like to be able to do this:

   git clone ssh://myserver/project.git
   git push

And have it work, but I keep getting errors about "/project.git" not existing in the root directory of my server. (Which is correct, they are stored elsewhere.)

The only documentation I could find about mapping a deep path to a "pretty" URL like this was in git-push(1) which stated I should add something like the following to a "config file". I'm guessing it means /etc/gitconfig on the server.

[url "ssh://myserver/path/to/repos/"]
   insteadOf myserver:

I'm a bit confused about where the colon comes into it, if I use that on the command line I get errors about resolving domain names. I've tried many variations of the insteadOf line ("ssh://myserver/", "myserver:/", "myserver/" etc.) but none of them make any difference. I don't even know if this file is being used.

Any pointers about how this URL mapping can be set up?

Many thanks, Adam.

(Please CC)

Adam Nielsen schrieb:

This form of URL can only accept the absolute path to project.git on myserver, eg.:

   ssh://myserver/home/adam/project.git

-- Hannes

Adam Nielsen <adam.nielsen@uq.edu.au> writes:

url.*.insteadOf is a configuration done on the _client_, i.e. the one that you run "git clone", "git fetch", "git push", etc. on.

	$ cat >>$HOME/.gitconfig <<\EOF
        [url "ssh://myserver/path/to/repos/"]
        	insteadOf = myserver://
	EOF
        $ git clone myserver://project.git

In any case, "attempting to learn Git" doesn't mix well with use of "insteadOf" to me. If you know /path/to/repos/project.git is what you want to access, any "attempting to learn Git" person would do more straight-forward "git clone ssh://myserver/path/to/repos/project.git", or "git clone myserver:/path/to/repos/project.git" which is even better (it is shorter to type and is a more natural form to spell ssh transport).

;-)

Hi all,

Thanks for the replies!

Jumping in the deep end is a valid method of learning :-) Does that mean anyone using my repositories really needs to know exactly where on the server I choose to keep them? Something like "git clone myserver:/mnt/raid/nightly-backedup/public/repositories/git/project.git" isn't particularly friendly. (It's something that bugs me with NFS as well.) What happens if I want to move the repositories to another area on the server? Do all users have to update their local copies with a new origin address?

Is there any hacky way that this could be made to work? I guess I could symlink my repository directory to /git, then myserver:/git/project.git might work.

What actually happens when you use the ssh:// style connection? git-daemon has a --base-path option which solves this issue for git:// URLs, so do ssh:// URLs not use the git protocol at all? What is git+ssh://? Does that SSH to the machine and then connect to git-daemon via localhost? Because that would presumably make use of --base-path.

Thanks again, Adam.

Adam Nielsen <adam.nielsen@uq.edu.au> writes:

Be it ssh://host/full/path or host:/full/path or host:path/in/home, you log in as whatver ssh identifies you as to the server, and start a server-side git process over there.

With ssh://host/path notation, there is no way to specify any relative path (i.e. "/path" part begins at root) so it will mean the same thing for everybody (unless you are getting chrooted or something), while host:path notation allows relative path which will be taken relative as where you are, i.e. home directory of the user on the server.

Ah ok, that makes more sense. Strange then if it's a server-side git process that it ignores the server's /etc/gitconfig where aliases can be set up.

In that case I symlinked my repository folder to /git so that SSH users can "cd /git/project.git" and this seems to work well. I can now use git URLs like ssh://server/git/project.git even though the repos are buried much deeper down in the tree.

Thanks for the explanations!

Cheers, Adam.