This document describes how to use Linaro Git Service. Note that there's separate Quick Reference page.

(A companion project: Code review server using Gerrit)



The new git server is running gitweb and gitolite.

gitolite is used to provide an authorization mechanism to access Linaro git repositories. With gitolite we can grant some users only read access, while giving read-write access to others. It is also possible to delegate repositories creation without having to connect to the server.

For more information on gitolite, refer to its user manual at:

Who can use it

Read-only access is available to everyone via HTTP and git protocol.

If you have a valid SSH key associated with your Linaro Login account, you can easily use it.

Changes from the previous service

  • Push URLs via the ssh:// protocol are changed: you need to update your local repository remote URL in order to use the new server. The new ssh:// URLs are now consistent with all the other protocol URLs.

  • People repositories paths changed: some of the repositories under the people/ have new paths. This is due to the fact that, in order to grant access to the repositories via gitolite, we are using the user name stored in Linaro Login. In order to mitigate this problem, symlinks have been created to point to the new location, but they only work with the HTTP and git:// protocols: if you need to push changes, you have to update the remote push URL to the new ssh:// one. Symlinked repositories will not be shown in the web interface.

SSH Keys

Please make sure your SSH keys on Linaro Login are valid and have been pasted correctly. The keys are synced every 30 minutes.

  • Make sure your key is just on one line: if you have more than one, they have to be on separate lines.
  • Make sure it does not contain empty spaces.
  • Make sure it starts with ssh-rsa or any other form for valid SSH keys.

Client configuration

With gitolite, all accesses happen via a single user called git: gitolite will then authenticate you based on your SSH key. (NOTE: Special-purpose git services may use other user than git, see instructions for a particular service.)

Typical operations quick reference

Available at ../Git.

Cloning a repository

Using the smart HTTP protocol (recommended)



The smart HTTP protocol has to be preferred over the git one.

Using the dumb HTTP protocol



Here $REPOSITORY_PATH must end with .git.

Using the git protocol (discouraged)

Please note that git protocol usage is discouraged and its support provided on reasonable effort basis, subject to resource constraints and limitations. Please do not use it for anything but debugging issues with other protocols!


git clone git://$REPOSITORY_PATH

Using your SSH key


git clone ssh://$REPOSITORY_PATH

Where $REPOSITORY_PATH is the repository you want to clone.
$REPOSITORY_PATH can either end with the .git extension or not, it doesn't matter.

Creating new repositories

See also Quick Reference.

At the moment, all users with their SSH key and a email address can create repository under the following path:


Where $USERNAME is your Linaro user name (usually in the form of name.surname as for Linaro emails).

Anyone can read repositories created under "people". Only the repository creator can push changes back.

Note: If you have more than one username defined in Linaro Login (ask IT Services), gitolite will use just one, the first one (usually name.surname).

To create a new repository on the server, all you need to do is to push it. Consider the following scenario, where a user creates a local repo, and then pushes it:

git init repo-test && cd repo-test
# Add files
git remote add origin ssh://
git push origin master

The previous command will create the repo-test repository on the server under people/john.doe.

This method applies to team repositories too (and special namespaces if you have access to them), not just personal repositories.

For each repository you create, please add description (see gitolite SSH interface below).

Team repositories space

It is possible to give other teams (or even just some users) the possibility to create repositories under defined paths, like a team space.

At the moment supported team spaces and their Linaro teams are:

Git Team Space

Linaro Team

















To create repositories under these paths, the instructions are the same as above (just modify the path accordingly).

To add new teams, please check with IT Services first if the team you would like exists. After that, ask IT to perform the required changes.

Deleting a repository

See also Quick Reference.

IMPORTANT: Only repositories created by users can be deleted (as opposed to repositories pre-created by an administrator directly on the server). Also, a repository can be deleted only by a user who created it, other users belonging to same "C" (create) permission group cannot do that. If you get "You are not authorised" error when trying to use commands above, run info -lc <repo_path> to show the creator, then contact them to perform the deletion.

Moving a repository to trash bin

Normal way to delete repository is to move it to the "trash bin", a special location on the server where removed repositories are stored and can be recovered.

Repositories moved into the trash will be kept for 30 days. After that time has passed, they will be automatically removed and it will be impossible to recover them.

To trash a repository:

ssh D trash path/to/repo

Important: the path to the repository should not include the trailing .git.

Immediate deletion of a repository

Only for admin usage - prefer usage of "D trash" command described above in all cases.

It is possible to delete the repository that you have created. Note that having write access to a repository is not enough to delete it.
The delete operation cannot be recovered: if you delete a repository there is no way to get it back.

In order to delete a repository:

ssh D unlock path/to/repository
ssh D rm path/to/repository

Important: the path to the repository should not include the trailing .git.

For more info on the D command:

ssh D -h

Pushing changes

Changes can only be pushed if you have your SSH key, and you are granted read-write access to the repository.

Push operations are plain normal: if you have read-write access nothing will change. If you only have read access, the push will fail.

Useful commands


ssh help

To get a full list of commands you can use via SSH to interact with gitolite and the repositories.

For more info on each command, run:

ssh COMMAND -h

To get a list of all the repositories you have access, and which access level you have, run:

ssh info

A brief legend of the permissions flag shown with the above command:

  • C: Create permission (you can create repositories under that path)

  • R: Read permission

  • W: Write permission

Adding repository description

See also Quick Reference.

ssh desc <repo> "<description>"


ssh desc infrastructure/linaro-git-tools "Helper scripts to manage Linaro git hosting service and repositories"

Copying repositories (forking)

See also Quick Reference.

In order to copy a repository for personal development, or to fork the development, there are two ways:

  1. Locally clone and then push into the new location (slow)
  2. Create a fork directly on the server (fast)

gitolite has a fork command, used to create a copy (fork) of one repository in a new location.
You need to have the C permission on the new location to create the new copy.

The syntax is as follows:

ssh fork <repo> <path>


ssh fork infrastructure/linaro-image-tools people/jon-doe/linaro-image-tools

Note: do not use the .git extension when typing the repository name.

Changing the default branch of a repo

To change the default branch of a gitolite repo, you can issue the following command, replacing <repo> as above and <branch> with the name of the new default branch:

$ ssh symbolic-ref <repo> HEAD refs/heads/<branch>

Concerns raised

Platform/Systems/GitServer (last modified 2017-03-16 13:53:24)