Git

How to get an account

IMM employees and Ph.D's can get a git account by sending an email to IT Service with your SSH public key which you find in ~/.ssh/*pub. E.g. ~/.ssh/id_rsa.pub.

If you don't have a public key then you can create one by

ssh-keygen -N '' -t rsa -f ~/.ssh/id_rsa

It is important that you keep your private key (~/.ssh/id_rsa) and public key safe and have a backup. Should someone get hold of your private key, then all your git repositories can get accessed by that person.

Disk space

By default the git admin get 1GB of disk space and a hard limit of 1,5GB, where all the git admin's repositories combined can not exceed these limits.

This means that if you have created e.g. 3 repos and have added some users to these, and if just one of these users adds a big file by mistake, and exceed the 1GB limit, then no one will be allowed to push to any of the git admin's repos.

If the disk usage is e.g. 900MB, and a user pushes a commit of 700MB, then the file system will stop writing when 1,5GB is reached, and there is a potential data loss for the repos owned by the git admin.

Linus is not shy to say that Git is not designed to contain big binary blobs. Example.

So 1GB is an enormous amount of space, if your uses use it as intended, so these limits should never be a problem. The limits are there however to protect the other git admin's repos, so a user from gitAdmin1 can not impact other admins' repos.

If you have a need for version control on big amounts binary blobs of data (e.g. images), then please contact IT Service and will try to find a solution for this.

Disk usage output

Everytime a git push is made by any of the git admin's users the total amount of used disk space is output.

Example:

mttj@pcmttj:~/git-test/test$ touch 7 && git add 7 && git commit -a -m "test" && git push
[master 25b388e] test
 0 files changed
 create mode 100644 7
Counting objects: 3, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 220 bytes, done.
Total 2 (delta 1), reused 0 (delta 0)
remote:                                                                 <-------------
remote: user4@git.imm.dtu.dk have used 3 MB out of 1000 MB.             <-------------
remote:                                                                 <-------------
To user4@git.imm.dtu.dk:test.git
   78b3caf..25b388e  master -> master
mttj@pcmttj:~/git-test/test$ 

If a user have made a big commit that have exceeded the quota limit then no one can push to any of the git admin's repo's.

Example:

mttj@pcmttj:~/git-test/test$ touch 8 && git add 8 && git commit -a -m "test" && git push
[master e223957] test
 0 files changed
 create mode 100644 8
Counting objects: 3, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 228 bytes, done.
Total 2 (delta 1), reused 0 (delta 0)
remote:
remote: user4@git.imm.dtu.dk have used 3 MB and exceeded quota of 1 MB.   <-------------
remote: No changes have been made to remote repository.                   <-------------
remote:
To user4@git.imm.dtu.dk:testgit
 ! [remote rejected] master -> master (pre-receive hook declined)         <-------------
error: failed to push some refs to 'user4@git.imm.dtu.dk:test.git'        <-------------
mttj@pcmttj:~/git-test/test$ 

Deleting a big commit

TODO

Rename or delete repo

TODO

Creating repositories and setting permissions

Once your account have been created, you can clone the gitolite-admin repo by

git clone dtuInitials@git.imm.dtu.dk:gitolite-admin

where dtuInitials should be replaced by your DTU initials which are 4 or more letters long.

This repository is where you create repositories, add users, and set permissions for the users.

The procedure to create a repo and add a user is:

• Specify the repo in gitolite-admin/conf/gitolite.conf
• Specify which users should be allowed and with what permissions
• Rename the users public key
• Add the users key to gitolite-admin/keydir/
• git add, commit, push gitolite-admin

All this will be explained in details in the coming sections.

Example

The git admin is the only one by default who can pull the gitolite-admin repo.

To add a repo edit gitolite-admin/conf/gitolite.conf.

Example:

@staff             =   dilbert alice
@projects          =   mobile fast_algo

repo @projects inv_prob
   RW+             =   @staff
   -       master  =   ashok
   RW              =   ashok
   R               =   wally

Aside from this the public keys from dilbert, alice, ashok, and wally have to be added, and finally everything committed and pushed.

Syntax

In general, everything is space separated; there are no commas, semicolons, etc., in the syntax. Comments starts with #.

User names and repo names must start with an alphanumeric, but after that they can also contain ., _, or -.

Usernames can optionally be followed by an @ and a domainname containing at least one . (this allows you to use an email address as someone's username). Repo names can contain / characters (this allows you to put your repos in a tree-structure for convenience).

There are no continuation lines by default. You do not need them; the Groups section will tell you how you can break up large lists of names in a group definition into multiple lines.

Groups

You can group repos or users for convenience. The syntax is the same for both and does not distinguish; until you use the group name it could really be either.

Here's an example:

@developers     =   dilbert alice wally

Group definitions accumulate; this is the same as the above:

@developers     =   dilbert
@developers     =   alice
@developers     =   wally

You can use one group in another group definition; the values will be expanded right there (meaning later additions will not appear in the second group).

@developers     =   dilbert alice
@interns        =   ashok
@staff          =   @interns @developers
@developers     =   wally

# wally is NOT part of @staff

@all is a special group name that is often convenient to use if you really mean "all repos" or "all users".

Adding and removing users

To add a user, e.g. Alice, obtain her public key (typically $HOME/.ssh/id_rsa.pub on her workstation), copy it to keydir with the user name as the basename (e.g., 'alice.pub' for user alice), then git add keydir/alice.pub. (All keys files must have names ending in ".pub", and must be in openssh's default format).

To remove a user, git rm keydir/alice.pub.

In both cases, you must commit and push. On receiving the push, gitolite will carry out the changes specified.

The user name is simply the base name of the public key file name. So 'alice.pub', 'foo/alice.pub' and 'bar/alice.pub', all resolve to user "alice".

adding and removing repos

NOTE: this page describes how to add new repos. To bring already existing repos into gitolite control, click here.

WARNING: Do NOT add new repos or users manually on the server. Gitolite users, repos, and access rules are maintained by making changes to a special repo called 'gitolite-admin' and pushing those changes to the server.

Just as for users, all operations are in a clone of the gitolite-admin repo.

To add a new repo, edit conf/gitolite.conf and add it, along with at least one user with some permissions. Or add it to an existing repo line:

repo gitolite tsh gitpod

   RW+     =   sitaram
   RW  dev =   alice bob
   R       =   @all

The "repo" line can have any number of repo names or repo group names in it. However, it can only be one line; this will not work

repo foo repo bar # WRONG; 'foo' is now forgotten

   RW      =   alice

If you have too many, use a group name:

@myrepos = foo @myrepos = bar

repo @myrepos

   RW      =   alice

Finally, you add, commit, and push this change. Gitolite will create a bare, empty, repo on the server that is ready to be cloned.

Removing a repo is not so straightforward. You certainly must remove the appropriate lines from the conf/gitolite.conf file, but gitolite will not automatically delete the repo from the server. You have to log on to the server and do the dirty deed yourself :-)

It is best to make the change in the conf file, push it, and then go to the server and do what you need to.

Renaming a repo is also not automatic. Here's what you do (and the order is important):

Go to the server and rename the repo at the Unix command line. Change the name in the conf/gitolite.conf file and add/commit/push.

moving existing repos into gitolite

Needs to be done on server side. Contact ITservice.

Accees rules

This is arguably the most complex part of day-to-day gitolite. There are several interconnected ideas that make this hard to lay out easily if you're totally new to this, so read carefully.

We will use this as a running example:

@staff = dilbert alice wally bob

repo foo

   RW+         =   dilbert     # line 1
   RW+ dev     =   alice       # line 2
   -           =   wally       # line 3
   RW  temp/   =   @staff      # line 4
   R           =   ashok       # line 5

what does a rule look like?

A rule line has the structure

<permission> <zero or more refexes> = <one or more users/user groups> The most common permissions used are:

R, for read only RW, for push existing ref or create new ref RW+, for "push -f" or ref deletion allowed (i.e., destroy information) - (the minus sign), to deny access.

Less commonly used types of permissions

Git supplies enough information to the update hook to be able to distinguish several types of writes.

The most common are:

RW -- create a ref or fast-forward push a ref. No rewinds or deletes. RW+ -- create, fast-forward push, rewind push, or delete a ref. Sometimes you want to allow people to push, but not create a ref. Or rewind, but not delete a ref. The C and D qualifiers help here.

When a rule specifies RWC or RW+C, then rules that do NOT have the C qualifier will no longer permit creating a ref.

Please do not confuse this with the standalone C permission that allows someone to create a repo

When a rule specifies RWD or RW+D, then rules that do NOT have the D qualifier will no longer permit deleting a ref.

Note: These two can be combined, so you can have RWCD and RW+CD as well.

One very rare need is to reject merge commits (a commit series that is not a straight line of commits). The M qualifier helps here:

When a rule has M appended to the permissions, rules that do NOT have it will reject a commit sequence that contains a merge commit (i.e., they only accept a straight line series of commits).

Activate the new repo and user

?

git clone git-owner@git.imm.dtu.dk:gitolite-admin

scp mttj@pcmttj:.ssh/*pub     gitolite-admin/keydir/mttj.pub
sed -i 's/mttj@pcmttj/mttj/g' gitolite-admin/keydir/mttj.pub

cd gitolite-admin
git add keydir/mttj.pub
vi conf/gitolite.conf
git commit -a -m "Added mttj pub key and RW perm to mttj on fast_algo repo"
git push

mttj can now access fast_algo repo by

git clone git-owner@git.imm.dtu.dk:fast_algo

Making the first git push to a new repo

git push origin master

Warnings and errors

• x11 forward
• space