Setting up git access for lab repositories

Created in April 17, 2022 by Shai Revzen, Marion Anderson

2022

Overview

This page has 4 “sections”

  1. Creating an ssh key that gets you access to the git server
  2. Configuring your machine to “find” the git server
  3. Test
  4. git overview

Some policies regarding git usage:

  • Do not add binary files larger than 512K to your repository. If you think you need to do that, contact the Professor for permission.
  • If you want to work on code, create your own branch and store it on the server. Name it with your initials in all-caps, e.g. SR for the Shai Revzen, created with git branch SR && git checkout SR. After you make changes, should then push that branch to the server with, e.g. git push origin SR
  • NEVER add a folder with git add. This tends to add garbage files that are then a lot of work to clean up. Especially on MacOS.
  • NEVER add IDE project and config files; lab policy is that all projects need to compile from the commandline. If you want to use an IDE, learn to use .gitignore to make sure it does not pollute the repository.

Background

The code repository we use is on a machine named tir-dol-ron.eecs.umich.edu, and it is served via a tool called gitolite. This tool provides access to a collection of git repositories on the basis of a static ssh (secure shell) key exchange. The idea behind this is simple: ssh provides a mechanism to verify the identity of a user by checking that she has the “private key” associated with a “public key” which is stored on the ssh server. When the user asks git to access the repository, the ssh config files are used to tell ssh to use a special private key unique to each repository user; that identity is cryptographically verified and a secure channel of communication is created, over which the repository updates are sent. All of this happens transparently to the user; she doesn’t need to type a password, or remember anything – except to be sure that the private key is not stolen.

(1) Getting Access

Create a key-pair

Create a public-private key pair using the command below

ssh-keygen -t ecdsa -f ~/.ssh/id_tir -q -P  ""

You should now have two files: the private key ~/.ssh/id_tir and the public key ~/.ssh/id_tir.pub

Getting the key-pair installed

Email ONLY your id_tir.pub key to the administrator and wait to be told it was “installed”

Note: If you email the private key (id_tir with no file extension), you will have to overwrite your key pair by repeating the creation step for security reasons.

(2) Configuring Your Machine

Make sure your ssh knows tir-dol-ron

First make sure that ssh “knows” tir-dol-ron, by typing the following command, answering “yes” at the prompt, and hitting ctrl-c when asked for a password.

ssh git@tir-dol-ron.eecs.umich.edu

This tests if you can even reach the server before you try to access it

Configure a host entry for tir-dol-ron in your ssh configuration

A few warnings here:

  • If you are repeating this step – nano ~/.ssh/config and edit the file
  • The instructions here assume that you do not have a ~/.ssh/config file. If you do, you need to edit it.
  • The END and Host in the command below must have no leading spaces.
  • This is for Linux. Windows setup requires some googling based on how you use Windows

Configure tir in the ssh config file:

cat >>~/.ssh/config <<END
Host tir
  Hostname tir-dol-ron.eecs.umich.edu
  IdentityFile ~/.ssh/id_tir
  Port 443
  User git
END
chmod 644 ~/.ssh/config

(3) Test whether everything is working

Now you can test whether everything is set up correctly. Give the command:

ssh tir

It should NOT ask for a password. Instead, you should get something like:

hello YourUserName, this is gitolite v2.2-13-gf0d712e running on git 1.7.0.4
the gitolite config gives you the following access:
     R   W 	pyckbot
     R   W 	python-libs
     R   W 	seal-wixel
     R   W 	wixel
Connection to tir closed.

where, of course, your repositories and access permissions may be different.

(4) Using the server, a.k.a. git intro

Working with submodules

Your project likely has submodules like pyckbot or mathmisc. https://git-scm.com/book/en/v2/Git-Tools-Submodules

Cloning a folder for first use

To get a copy of a folder in the git repository for the first time, use the clone command, for example: git clone tir:repositoryName

Checking status

Inside your git folder, for example in pyckbot, you can check the status of your ‘Working Directory’ using the command

git status

You can see a list of “Changes not staged for commit” in the response. For example:

# On branch master
# Your branch is ahead of 'origin/master' by 7 commits.
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	    modified:   gait_optimizer/robot_runner.py

To get ready to commit a changed file, use the command:

git add <file>

Now if you execute the command git status you will see the file listed under the response section titled “Changes to be committed.” If you are ready to commit, use the following command to commit the change to the ‘head’ of your local code copy:

git commit -m "Your message aka short description of changes here"

If you want a gui for doing your commits, a good tool to have handy is meld, installed with sudo apt install meld.

Adding a new repository

You need to ask the administrator to create a repository for you. Once it is ready, you should clone it. You will get a warning about cloning an empty repository; this is normal.

The first time you push (already locally committed) changes to the empty repository you need to tell git that this will be the master branch, using

git push origin master

There are many git tutorials that go into varying levels of depth online. A simple tutorial covering most of the above and a bit more information can be found here.