Using our Git Server


(If you don't know what an SSH public key is or don't know how to generate a key pair, your can read from GitHub. Just ignore all the parts that are specific to GitHub.)

Note that you need to follow these steps for each computer than you plan to use. Also note that EPFL members that are not part of the lab (e.g. students) should the link for step 2.

  1. Make sure you have installed Git on your machine.
  2. Go to to add your public SSH keys to the system.
  3. While you are there, make sure your identity is: “First Last < >”. This is what will identify you as the author of commits in the history of repositories.
  4. You should be all set. You can check your configuration by running ssh info from a terminal. It should give you something that looks like this:
  $ ssh
  hello username, this is gitolite v2.2-1-g66634d6 running on git
  the gitolite config gives you the following access:
    C  R   W 	    papers/[a-zA-Z0-9].*
    C  R   W 	    projects/[a-zA-Z0-9].*
    C  R   W 	    software/[a-zA-Z0-9].*
    C  R   W 	    teaching/[a-zA-Z0-9].*

Know Your Rights

You can run ssh info.

  $ ssh info
  hello psuter, this is gitolite v2.2-1-g66634d6 running on git
  you have access to the following repos on the server:
       R   W 	    (psuter)	    papers/adt-synthesis
       R   W 	    (psuter)	    projects/leon-kaplan
       R     	    (edarulov)	    projects/mathcheck
       R   W 	    (ekneuss)	    teaching/cc-interface
       R   W 	    (psuter)	    teaching/compilers
      @R_ @W_	    <gitolite>	    testing

As you might expect, R means read, W means write, and the name in parentheses is the name of the creator, who happens to be the person who can change the rights (Fabien can also reassign that role).

Cloning an Existing Repository

…is simple:

  $ git clone

If you plan to commit to a repository, you should make sure that your Git identity clearly identifies you (e.g. it matches what you have entered in the web interface at setup, hopefully, “First Last < >”).

You can check this by running, from within the repository:

  $ git config --list

Look for the properties and If they appear several times, the last occurrence is the one that counts. If you need to change them, run:

  $ git config First Last
  $ git config

If you only use Git for your LARA-related work, you may want to add the –global flag to git config; that will set these values for all repositories. Otherwise, you need to set them each time you clone a LARA repository.

Creating a New Repository

…is done simply by cloning an empty repository (it must be a subdirectory of either papers, projects or teaching). You may need to ask Fabien for that right (only once).

  $ git clone
  Initialized empty Git repository in .../fermat-wrong-after-all/.git/
  Initialized empty Git repository in /home/git/repositories/papers/fermat-wrong-after-all.git/
  warning: You appear to have cloned an empty repository.

As Git is telling you, you have just cloned an empty repository. You can now add files, etc, as you would with any repository. You are by definition the creator of it, as you can confirm that by running

  ssh info

That means you and only you can change permissions. Note that if you haven't set these things globally, it's a good idea to run

  $ git config First Last
  $ git config

to make sure you'll be properly identified when you commit something.

Working Way of Setting Permissions

The only thing that matters once you created repo is that kuncak has access to it. So, do this:

ssh perms papers/p-equals-np + WRITERS kuncak

OLD WAY OF Setting Permissions

(This does not seem to work any more.) It's convenient to have a file called PERMISSIONS in the root directory of the repository that looks as follows: (OUTDATED!)

  # Just editing this file won't affect the permissions. After editing it, you
  # also need to execute it.
  # The creator of this repository is YOUR_USERNAME.
  tail -3 "$0" | ssh perms ${thisrepo}
  exit $_
  # **Do not** add new lines after the following three!
  OWNERS  kuncak fsalvi YOUR_USERNAME
  READERS @lara

It serves two purposes:

  1. It documents the access rights.
  2. When the creator of the repository executes it, it updates the rights.

As you would expect, WRITERS can commit to the repository, READERS can only read from it. (Note that it's fine to have an empty list of READERS, for instance.) Use @lara as a shorthand for your group of comrades. OWNERS is a new role which allow to set the permissions to the repository (eg to allow other people to add new commiters).

If the file doesn't exist, you can get the permissions with:

  ssh perms -l <repository>

Importing a Repository from SVN

It is possible to move a repository from SVN to Git while preserving the complete history. Here's how.

  1. Clone the SVN repository: git svn clone This will likely take a while, as Git will replay all revisions to store them in its own commit format. (If you can't remember where your repository is, run svn info or take a look in .svn/entries.) You now have a Git representation of your SVN repository. Note that if for some reason the clone command doesn't complete (e.g. because the SVN server stopped responding at some point), there's no need to start all over; you can resume it by running git svn fetch.
  2. Emancipate yourself: cut the tie to the source repository by running git remote rm origin.
  3. Now set a new “source”, by adding a remote branch: git remote add origin
  4. Push it to the server: git push.

The above procedure will move the entire contents of the SVN repository to a new one. If you only want to move a selected subdirectory, you will need to filter the repository first. Take a look at this StackOverflow question. It assumes you're starting from a Git repository, but that's exactly what you have after the git svn clone command.