.git
. The key thing about a bare repository is that users with write permission can push changes up to the repository. So instead of giving read access to your personal working repository so that others can keep in sync, you push changes to the bare repository and others pull updates from that. ssh your-ccid@gpu.srv.ualberta.ca
If you have not ssh'd to the gpu server before, it will ask if you trust this RSA fingerprint with a message like this: The authenticity of host 'gpu.srv.ualberta.ca (129.128.5.145)' can't be established.
RSA key fingerprint is 96:7f:97:5d:23:1c:bc:2b:3a:dc:fb:22:8b:78:47:9b.
Type 'yes' if you are doing this from a U of A lab or UWS. If not from a U of A lab or UWS, then potentially this is insecure, but generally not a problem. You should check that the fingerprint matches the above. chsh
, which will set your login shell to bash: chsh -s /usr/local/bin/bash
Important. You need to do this twice. When you login, your prompt will look something like this: your-ccid@login1$
or your-ccid@login2$
Note the login1
or login2
indicating which of the two login machines you are working on. It is important that your shell be changed on both machines. So, for the machine not mentioned in the prompt, say login2
, you need to repeat the change shell command on the other machine. So, while still logged in to gpu, temporarily login to the other machine: ssh your-ccid@login2
chsh -s /usr/local/bin/bash
# exit the login to login2 exit
echo $SHELL
~jhoover
. This means that you have to add the path ~jhoover/bin
to our Git executables to your PATH
variable. This has to be done in your .bashrc
file, since that is the only file executed when you issue remote commands. But, since .bashrc
is executed everytime you use bash, nested invocations of the shell can result in the path being extended every time. Thus there is code to only prepend to the path when the shell level is missing or at level 1. cp ~jhoover/bin/bashrc-template ~/.bashrc
# sample .bashrc for gpu logins |
alias rm='rm -i' |
alias cp='cp -i' |
alias mv='mv -i' |
alias ln='ln -i' |
alias ls='ls -F' |
alias df='df -k' |
alias du='du -k' |
alias vi='vim' |
# No EOF to close shell |
export IGNOREEOF="Yes" |
|
# prompt |
export PS1='\u@\h\$ ' |
|
# add my bin and ~jhoover/bin to path, if this is the first time through |
# change ~jhoover to where the Git executables are actually located |
|
if [[ ( "$SHLVL" == '' ) || ( "$SHLVL" == '1' ) ]] |
then |
export PATH=~/bin:~jhoover/bin:$PATH |
fi |
|
export PATH=~/bin:~jhoover/bin:$PATH
.bash_profile
is executed. So you also need to have your .bash_profile
, process your .bashrc
file. To do this, make sure .bash_profile
has this line in it at the end: source ~/.bashrc
ssh your-ccid@gpu.srv.ualberta.ca 'echo $PATH'
and you should get something like this: /u/j/h/jhoover/bin:/u/y/o/your-ccid/bin:/usr/bin:/bin:/usr/afs/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin
You can also check the remote environemnt on gpu by doing this: ssh your-ccid@gpu.srv.ualberta.ca printenv
The values of the environment variables will tell you what shell is running etc.
fsr-sa
which applies the AFS changes recursively to every subdirectory of the given directory. There is a version of fsr-sa
in ~jhoover/bin
. fsr-sa
into your ~/bin
directory: code/git/fsr-sa #!/usr/local/bin/bash |
# Recursive AFS set access |
# invoke with: |
# fsr dir user-id perms |
# does a recursive 'fs sa' on dir and all its subdirectories to set |
# the user-id to have permissions given by perm |
# typical permissions: read, write |
# typical user-id: system:anyuser, or a specific ccid |
# |
find $1 -type d -exec fs setacl {} $2 $3 \; |
~/bin
, and make fsr-sa
executable using chmod a+x ~/bin/fsr-sa
repos
directory where you put all your shared repositories. fredflint
and laracraft
, and that your shared bare repository is going to be called project1.git
fredflint
and laracraft
read and write access to the repository. # change to home directory
cd
# allow others to navigate through your home directory
# but not read it fs sa ~ system:anyuser l
# make a publically readable directory to hold your repos
mkdir repos
fs sa repos system:anyuser read
# change to the repos and
# create a bare repository called project1.git
cd repos
git init --bare project1.git
# make it and subdirectories writable to your team
fsr-sa project1.git fredflint write
fsr-sa project1.git laracraft write
fs la ~/repos/project1.git
and you should get an output something like this: your-ccid@login1$ fs la project1.git
Access list for project1.git is
Normal rights:
webservers l
system:administrators rlidwka
system:anyuser rl
your-ccid rlidwka
fredflint rlidwk
laracroft rlidwk
project1.git
repository that you just created on gpu. You do this with the clone command (be careful with the number of / characters!) git clone ssh://your-ccid@gpu.srv.ualberta.ca/~your-ccid/repos/project1.git
and you should get an output like this: Cloning into project1...
your-ccid@gpu.srv.ualberta.ca's password:
warning: You appear to have cloned an empty repository.
which indicates that you now locally have a git repository called project1
that is tracking the main one on gpu. myproject
, you simply do a git init myproject
which will create the directory myproject
and initialize it as a Git repository. Everything under myproject
will now be under version control. Git creates a hidden directory myproject/.git
where all of the information about all versions you have ever committed is stored.
git clone [location of the repository you want]
The origin can be located in various places, such as on your own machine. But we be using ssh to synchronize our Git repositories, so the origin location will be in the form //your-ccid@gpu.srv.ualberta.ca/~ccid-of-repo-owner]/[path-to-repo-from-owner-home-directory]
as illustrated in the previous section when we cloned project1.git
. pull updates,
edit local changes,
get status,
add changed files to the index,
commit the changed files,
possibly push updates to the origin,
repeat
git add [file you want to add]
This tells git that when you commit a version, it should save the current state of this file.
git status
git commit -am 'What happened in this commit'
This tells git to store all of the tracked files so that you can return to them later or share them with other developers.
git checkout file-name
git checkout file-name
git pull
This will take any changes they have made to their repo and reproduce them in yours. If there are conflicts, git will alert you. If this is the case, go to each file in which there are conflicts and choose how to take the merged pieces from the different repositories and consolidate them into a working file. Once everything looks right and runs (if applicable), do a commit to store the new merged version. Once you have done this, you can request your fellow student pull from your repository. At this point your repositories should be the same.
git push origin master
If additional changes occurred on the remote after your last pull, you may have to pull again if the push gives you a error message.
git log
sudo apt-get install git
cd git-1.8.0
gmake NO_PYTHON=1
gmake install NO_PYTHON=1
This will put git things into your ~/bin
and ~/share
directories.
fs
command is the AFS file utility, and the sa
option is for setting access.
cd
find bin -type d -exec fs sa {} system:anyuser read \;
find share -type d -exec fs sa {} system:anyuser read \;
fsr-sa ~/bin system:anyuser read
fsr-sa ~/share system:anyuser read
25. Git Tangible Computing / Version 3.20 2013-03-25 |