Introduction

git is a source control management tool similiar to CVS or SVN. This tutorial will give enough information to:

• create a central git repository on your MetaARPA account
• clone that git repository to your off-site computer
• sync your changes with your repository copy on sdf
• create a public readonly copy of your repository

Configuring your account to use git on sdf

First, you must be MetaARPA to use git.

Second, it may be necessary to update your $PATH on the main cluster to include git. The git pkg installs most binaries you need in /usr/pkg/libexec/git-core. This needs to be in your PATH. The easiest solution is to include the following in your ~/.profile:

export PATH=/usr/pkg/libexec/git-core/:${PATH}

If this is necessary and you plan on accessing the repository remotely over SSH, be sure this is done even on non-login shells. This may require including it in .kshrc, .bashrc, .zshenv, .cshrc, etc.

Now any SSH session will have the necessary git binaries in the PATH.

Creating a central git repository on SDF

Create the server repository

    mkdir -p ~/git/myproject
    cd ~/git/myproject
    git --bare init
  

Note that the path is arbitrary and can be anywhere in your home directory. This can be done either on the Meta Array or on the main cluster.

And that's it! on the server side. This remains empty until you first "push" your project to the server.

Creating your local git repository.

On your local machine, let's assume you already have a project you want to start watching under git, with the files

• ~/proj/
• ~/proj/include
• ~/proj/test.c
• ~/proj/include/test.h

First, initialize the git project:

    cd ~/proj
    git init
  

Now your repository is initialized! Time to check in your current project. First we add the files to the repository. I like to manually add each file instead of doing a "commit all" because "commit all" tends to collect files you never wanted to add to source control (object files, temp editing files, etc).

    git add test.c include/test.h
    git commit
  

If the commit failed, follow the directions onscreen to configure your username and email so git can track you as a user in the repository.

Now time to connect your local copy to the repository on the main cluster:

    git remote add origin user@sdf.org:git/proj
    git push origin master
  

Or, if you created your repo on the Meta Array, set up your remotes like this:

    git remote add origin user@ma.sdf.org:git/proj
    git push origin master
  

Git should ask for your password, and then tell you it uploaded the objects and that everything succeeded.
If not, ask on the sdf forum for advise.

Copying (cloning) your central repository to a client machine

Last thing: Now that you have a central copy, how do you check it out? use git clone from your local machine:

git clone ssh://user@sdf.org/~/git/proj

If your repo was created on the Meta Array, adjust accordingly:

git clone ssh://user@ma.sdf.org/~/git/proj

Backing up all your existing git repos to a remote server

• check your git repo for any changes
• if changes exist, tar up all your git repo
• ftp it to another host

The script, git-backup.sh

#!/usr/pkg/bin/bash

cd ~/git
mv git-summary git-summary-old
for i in *.git; do
  cd $i
  git log --pretty=oneline >> ../git-summary
  cd ..
done

diff git-summary git-summary-old
if [ "$?" != "0" ]; then
   #tgz up the whole git directory with today's date
   cd ..
   rm git-latest.tgz
   tar -cvzf git-latest.tgz git
   ftp ftp.your-host.com <<WOOPWOOPWOOP
   cd git-backup
   rename git-latest.tgz git-backup.tgz
   put git-latest.tgz
   quit
WOOPWOOPWOOP
fi

Note: For the FTP to work, edit your ~/.netrc file so that ftp.your-host.com has an entry that looks like:

machine ftp.your-host.com
    login your-user-name
    password your-password
    bin

Updating your local copy with changes made to the repo

git remote add origin user@sdf.org:git/project

git fetch

git merge

Creating a public access, read only repo

Setup some webspace

hooks/post-update

In your repo directory for the project there is a directory that contains a set of scripts which are called at different times during your interaction with git. For more information about the "hooks" directory check out githook.

The script we will need to modify is post-update. This script is called after an update has occured on the server side of your repo.

#!/bin/sh
#
# File: ~/git/proj.git/hooks/post-update
#
# Description: Called when an update is pushed to the server
#

# Location of your repo on the server
GIT_DIR=/arpa/tz/u/user/git/proj.git

# Location of your public version of the repo
HTTP_DIR=/arpa/tz/u/user/html/devel/proj.git

# Update local repo info
git update-server-info

# Make sure a clean copy is moved
rm -rf $HTTP_DIR
cp -rf $GIT_DIR $HTTP_DIR
chgrp -R nobody $HTTP_DIR

# Directories must have Read and Execute Permissions
# for apache to be able to navigate them.
for d in `find $HTTP_DIR -type d`; do
  chmod a+rx $d
done

# Files must have Read Permissions for apache
# to be able to read them.
for f in `find $HTTP_DIR -type f`; do
  chmod a+r $f
done

# Display a message on the client side to show 
# the action has been performed.
echo "Updated Public Access"

Now that you have setup this script make sure its executable.

You can now run the script directly or wait until you have committed and pushed an update to your server.

Verifying script is run.

When you push an update to your private development repo, a new output has been added by our script.

$ git push
Counting objects: 5, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 256 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Updated Public Access
To user@sdf.org:git/proj.git
   e60a9de..1f8a43f  master -> master
$

In the above example there is a new line labled "remote" which means that during the push, the server produced output. The line matches the last line in our post-update script. Now you have two methods of access.

Allowing Multiple Users git Access

Create SSH Key

# ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/joe/.ssh/id_dsa): /home/joe/.ssh/sdf-dev
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/joe/.ssh/sdf-dev
Your public key has been saved in /home/joe/.ssh/sdf-dev.pub.
The key fingerprint is:
6e:aa:25:bb:2e:ec:ee:93:ff:ef:a1:21:8a:fe:df:fc joe@mypc
The key's randomart image is:
+--[ DSA 1024]----+
|+++.+.           |
|=*+ ..    =+     |
|*++   .  - ..    |
|.o ..= S         |
|  E   . S        |
|     o   .  o +  |
|  ++  .          |
|  +      S  o    |
|     +++         |
+-----------------+
# ls /home/joe/.sdf
sdf-dev sdf-dev.pub

Create a git access script

#!/bin/sh
exec git-shell -c "$SSH_ORIGINAL_COMMAND"

The $SSH_ORIGINAL_COMMAND variable contains the commands issued with your ssh session (try logging in with ssh localhost ls).

Add User to Authorized Keys

command="/arpa/gm/f/frank/gitaccess.sh",no-port-forwarding,no-agent-forwarding,no-x11-forwarding,no-pty ssh-rsa AAAB3...

All the no-* flags disable all other types of ssh access (Port Forwarding, X11, PTY) so we only get git access and nothing else. Now if your friend uses your user name and his/her ssh key to connect to your git server they will be able to clone, pull, commit, etc. just as if they were you. Make sure they set their global settings in their git client so you can see your history correctly.

TODO