git is a source control management tool similiar to CVS or SVN. This tutorial will give enough information to:
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
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.
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.
On your local machine, let's assume you already have a project you want to start watching under git, with the files
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 firstname.lastname@example.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 email@example.com: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.
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://firstname.lastname@example.org/~/git/proj
If your repo was created on the Meta Array, adjust accordingly:
git clone ssh://email@example.com/~/git/proj
#!/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 binAlso ensure to run "chmod 600 ~/.netrc" to hide your credentials to the rest of the world :). Now add this to your (daily or less) cron tasks with mkcron (MetaARPA only, just like git ;) and enjoy your timely backups!
git remote add origin firstname.lastname@example.org:git/project
originis the nickname for the repository on
sdf.lonestar.org. Then, you do
git pullto do a fetch followed by a merge. This is unlike CVS and Subversion, where
pull. The two commands are provided because your local repo is not meant to be a copy of the remote, so you need to be able to fetch the remote without merging it into your local repository.
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.
chmod a+x ~/git/proj.git/hooks/post-update
You can now run the script directly or wait until you have committed and pushed an update to your server.
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 email@example.com: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.Private Access: git clone firstname.lastname@example.org:~/git/proj.git
# 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
#!/bin/sh exec git-shell -c "$SSH_ORIGINAL_COMMAND"
$SSH_ORIGINAL_COMMAND variable contains the commands
issued with your ssh session (try logging in with
ssh localhost ls).
authorized_keysfile. This will be a little different than you normally would enter one, as we want to force the user to run our git access script instead of a normal shell. At the end just paste the contents of the public key as you normally would.
command="/arpa/gm/f/frank/gitaccess.sh",no-port-forwarding,no-agent-forwarding,no-x11-forwarding,no-pty ssh-rsa AAAB3...
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.