Git repository URL - SSH syntax without absolute path

If you use the alternate form of ssh URLs you don't need an absolute path. For example...

git clone [email protected]:repos/myrepo.git

...will clone repository repos/myrepo.git relative to my home directory, although this doesn't permit use of an alternate port. However, you can also use ~ in either form to indicate the user's home directory, e.g.:

git clone ssh://[email protected]:12345/~/repository.git

Incidentally, despite being discontinued, gitosis functions quite well, and the code is both small and easy to understand. It offers a useful set of access controls and self-service management of repositories. I wouldn't discount it completely.


I do this, not exactly what you asked, but close and with prettier links:

create a path like

/srv/git 

where you place you git projects

next make a symbolic link to home:

ln -s /srv/git $HOME

next you can have shorter links

git clone user@server:git/myproject.git

if you have a single project you can get rid of the git/ part in the url

ln -s /srv/git/myproject.git $HOME

next

git clone user@server:myproject.git

will work. Of course the .git at the end of the URL comes only from creating the bare with .git in the name. Note also that ssh:// part is not needed: the @ implies it is an ssh URL for git.

Updated: let me add a sidenote: following the most recent Filesystem Hierarchy Standard I use now /srv/git as repository location.


I'm not sure this really deserves to be a whole answer, but I'm sick of fighting with comment-specific formatting rules. I come to say:

I just want to add that this seems to be a version-specific change, though I'm not sure if it's client-side or server/repo-holder side: I have a .git/config file with lots of URLs like:

[remote "bob"]
    url = ssh://ME@MACHINE<strong>/~ME</strong>/repositories/REPO.git
    fetch = +refs/heads/*:refs/remotes/bob/* 

They all worked when I set them up ... in 2010, and were still working the last time I used those remotes, in 2016 or so.

Now, on version 2.18.0, those don't work, and I need to use the :/~ME/foo or :/~/foo notation. Which is to say that what you're trying to do no hasn't always been wrong.