See "How do programs like gitolite work?", and check the ~ubuntu/.ssh/authorized_keys
file on the gitolite server.
You will see that file is set to call the gitolite script with the user name as registered in that file.
The ssh user is always git
(or whatever user you had to install gitolite, in your case, I presume 'ubuntu
').
The "interception" part is actually called ssh forced command, which means the ssh session returned isn't an interactive one, but will always call a script (here the gitolite script).
That means you shouldn't have to change the git repo url.
The name of the public key you add to gitolite (through the gitolite-admin
repo in gitolite-admin/keys
serves to register the name of the user as a parameter to the call of the gitolite script in the ~ubuntu/.ssh/authorized_keys
.
It is not a set of git hooks (except for the update
hook, see below)
It is an authorization layer which stands between ssh and git.
Instead of ssh calling the git
command directly, ssh calls the gitolite
perl script which calls git if the user is authorized to proceed.
You can use gitolite to register special hooks for repos: see "hooks and gitolite", and hooks.
Gitolite will regsiter an update hook for all gitolite-managed repos, in order to managed VREFs hooks.
The updated Gitolite presentation by its author has an interesting schema to summarize the all process: