immerda:GitRepositories
Git Repositories
git @ immerda - Quickbox
Repository URLs
immerda.ch provides access to git repositories. Either single repositories on our general git-storage or your very own repository storage, that you can manage completely on your own.
General Information
To manage access and authorization of a git repository storage, we use gitolite. So any information regarding how you can configure your different repositories can be found in gitolite's documentation.
To make it possible to browse your repositories on the web, we use cgit, which can be publicly available or protected by htpasswd.
What you can get
If you are a friend of us, you can get your own repository storage on our servers. Simply get in touch with us and we can create you either access to your own repositories on git.immerda.ch or your very own repository storage, where you can manage your own access and give access to your friends without involving us. While you can configure a lot on your own, there are a few decisions you need to make before ordering your own repository storage.
Should your repository storage:
be available by other means than ssh?
Depending on the setup of your repository storage, you can access your git repositories by different means: ssh, git, http(s) . You can also configure the access to your repositories for these different protocols using the gitolite config file on a repository basis. But still you need to tell us by which protocols your repositories should (potentially be available).
Access by http(s) will include the cgit webinterface to browse your repositories. But it can still be made non-public by allowing access only to these users, that can authenticated against ssh for your repository storage.
be publicly available for anonymous pull?
If you do not want to have only private repositories for your own non-public project and share your work (for example on free software projects) with the world, you might want to make them available for anonymous/unauthenticated pulls. This can happen over the git-protocol or http(s). Depending on which protocols you have chosen before, this will either be additionally only over authenticated https or if you want to share your work with the public by unauthenticated http(s).
be accessible with which domain name?
Which domain name will be used to access your repositories? This will be your domain to access your repositories, either by ssh, git or http(s) protocol.
use which login name?
You have to choose a login name for your repository storage. This will be the login name that you can use access your repositories by ssh. Also if you choose to make it possible to browse your repositories by http(s), you will also be able to access them by http(s)://git-LOGINNAME.immerda.ch using a correct certificate for the domain name.
As a bonus point we can set you a dedicated cgit-logo if you provide as one.
Configuration
As mentioned earlier: We use gitolite to manage access and authorization to your repositories, so gitolite's documentation is a good starting point to learn how you can configure access to your different repositories.
SSH
All repository storages are available over the ssh protocol using public-ssh keys to authenticate you as an user. For more information we refer to gitolite's documentation.
Access URL for your repository will look like:
ssh://LOGINNAME@git.yourdomain.com
daemon / git-protocol
If you want to make your repositories available by the git protocol, you will need to allow read-access for the daemon user:
repo some_repo RW = @developers R = daemon
You will then be able to clone these repositories by
git://git.yourdomain.com/some_repo.git
http(s)-protocol
If you want to make a repository appear in the webinterface cgit (and accessible via anonymous http(s)), you need to - similar to the git-protocol - give read access to the daemon user for this repository. Additionally you have to set gitweb options for the git config that will be read by cgit and for example label your repository in the webinterface. Otherwise your repositories won't show up in cgit.
repo some_repo RW = @developers R = daemon config gitweb.owner = "Ada Lovelace" config gitweb.description = "My repository"
Repositories that are published in a public cgit can be cloned using anonymous http(s). So you will be able to clone any repository that is avaiable in cgit with the following command:
git clone http://git.yourdomain.com/some_repo
If you have given your user an htpasswd (see below on how to do that), you will also be able to push changes to that repository over https. Either using
https://git.yourdomain.com/some_repo
or
https://git-LOGINNAME.immerda.ch/some_repo
htaccess
If you enabled http(s) as one of the protocols to access your git repositories, you can set a password for your username (in gitolite's config) using gitolite's htpasswd command:
ssh LOGINNAME@git.yourdomain.com htpasswd
This will set the login name for your gitolite user. And you will be able to push changes to your repositories by https using your gitolite-username and the set password.
https access to non public repositories
As mentioned earlier, you can also clone & fetch any published repositories using the smart-http protocol. However, you are also able to access any non-published repositories using the https-protocol using the configured htpasswd authentication (see above) to authenticate yourself. For technical reasons, you need to prefix such non-public repositories with the following path _gl/. This means that your hidden_repo.git will be available using the following url:
https://git.yourdomain.com/_gl/hidden_repo.git # or with the correct certificate https://git-LOGINNAME.immerda.ch/_gl/hidden_repo.git
This prefix is only required for repositories that are not published in cgit. A good example is for example the gitolite-admin.git repository, which you might not want to publish in cgit, but still push changed to it over https.
wildcard repositories with create rights
repo somedir/..*
C = u1
RW+ = u1 u2
This means, that u1 can create any repositories under somedir/ by using a simple `git clone git@git.yourdomain.com:somedir/foo.git . u2 can push to any existing repository.
commands
Gitolite provides a set of basic commands to run commands on the repository storage for a certain user. One example is the htpasswd command mentioned above or the hooks command in the next section.
You can get a list of possible commands by calling:
$ ssh LOGINNAME@git.yourdomain.com help
Additional help for a command can be printed by calling this command with -h. Example:
$ ssh LOGINNAME@git.yourdomain.com desc -h
Usage: ssh git@host desc <repo>
ssh git@host desc <repo> <description string>
Show or set description for user-created ("wild") repo.
Calling the repository storage without any command provides you a list for repository you have access to and the specific access rights.
Hooks
Hooks can be very comfortable to run additional commands for example before or after you pushed updates to your repository. To ease administration of hooks on your repository we provide you as a repository storage owner (gitolite user than can write to gitolite-admin) with gitolite command to manage hooks on repositories:
$ ssh LOGINNAME@git.yourdomain.com hooks -h
Usage: ssh git@host hooks show <repo> <hook> # Shows current active hooks for repo.
ssh git@host hooks list [<hook>] # List available hooks for a certain type. If <hook> is omitted all hooks are shown.
ssh git@host hooks add <repo> <hook/script> # Add a certain script to a hook - this must be named like hook/script.
ssh git@host hooks rm <repo> <hook/script> # Removes a certain hook script from a repository.
Only users with write access to the giolite-admin repository can show, add or rm hooks from a certain repository.
To minimize possible attack vectors on our system you are only able to add hooks we previously reviewed and activated for global usage. You can get a list of possible hooks by running the list action on the specific command:
$ ssh LOGINNAME@git.yourdomain.com hooks list post-receive: email-notification
Example to activate the hook:
ssh LOGINNAME@git.yourdomain.com hooks gitolite-admin post-receive/email-notification
post-receive/email-notification
Sends an email to a certain address (config hooks.mailinglist option on your repository) about the recently pushed changes. You will need to set at least the option hooks.mailinglist for your repository:
repo gitolite-admin RW = @gitolite-admin config hooks.mailinglist = 'gitusers@example.com' config hooks.envelopesender = 'git@example.com'
You can also easily activate this config setting for all repositories:
repo @all config hooks.mailinglist = 'mh@scrit.ch' config hooks.envelopesender = 'git@scrit.ch' repo gitolite-admin RW = @gitolite-admin
The behavior of this hook can be configured by different options:
- hooks.mailinglist - required - Receivers of emails
- hooks.announcelist - Additional receivers of pushed tags
- hooks.envelopesender - sender of the email
- hooks.emailprefix - Prefix of the emails subject. Default: [SCM]
- hooks.generatepatch - Should we include a diff of all the pushed changes? Default: true
You can get more Information at:http://git.puppet.immerda.ch/?p=module-gitolite.git;a=blob;f=files/hooks/post-receive/email-notification
More
Expect more hooks to come. Get in contact with us if you miss one.