Re: Unable to get "pretty" URL aliases working

Adam Nielsen [off-list ref] writes:

I'm attemping to learn Git but I've gotten stuck trying to configure a
server to host my repositories.
...
[url "ssh://myserver/path/to/repos/"]
  insteadOf myserver:

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!

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

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 [off-list ref] writes:

What actually happens when you use the ssh:// style connection?

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.

quoted

What actually happens when you use the ssh:// style connection?

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.

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.

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.

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.