From SLangTNG


Git interfaces

This page gives a short overview on what Git is, in which use cases it can be applied and where to check out data from.

What is Git?

Git is a versioning system such as RCS, CVS, SVN, Mercurial, etc. It helps to administrate the source code of TNG including versioning control, locking, merging changes etc. The basic idea is that a central repository is located at a special file server. Developers may communicate via Git with this repo in order to tell the other developers which changes he made, and to obtain the changes of the other developers being made to the source tree.

The reasons for using Git in opposite of CVS and SVN are

  • high flexibility (providing many different use cases) needed for establishing a community and interact with third-party developers.
  • distributed network capabilities - commit changes without being online.
  • minimal memory and network requirements
  • an active supporting community (originally used by Linux kernel developers)

The logic behind Git is quite different compared with CVS and SVN, but once learned is as simple as the others.

Possible use modes

There are different use modes available when using git:

  • individual repo clones:
    Every user updates and clones against other users. This is only recommended when the developer team is very small.
  • master users:
    Every user clones against a master repo. When changes are to be committed, the master user will be informed and he will "pull" the changes from the user. Changes may be reviewed, accepted or declined. This is recommended when third-party developers try to commit code.
  • Shared repository:
    A central repo is cloned from the master repo being tagged as "shared". Users who clone the shared repo can "push" their changes to the shared repo. This is a probable choice for internal developers, see sections "Editing" and "Working with a shared repo"
  • A public repo serves as a public mirror which is not intended as working repository, but as interface for others in the outside world to fetch from.

Workflows of the configured repositories


                                      user commits changes 
                                         to temp. branches
                     user pulls               V
 master repo   ----------------------->   user repo
 with changes                                 |
      ^                                       |                             
      | reviews changes and                   |  user merges possible conflicts and
      | merges user branch                    |  continues his work
      |                                       |                             
      |                                       V
 master repo  <-----------------------    user repo 
                   master fetches        with changes

Clone the repository:

git clone user@servername:location myrepo

which creates directory "repo" containing a copy of the repository. The copy is a real "copy" with its own history and management!

You can commit to your own repo as long as you wish. When being finished the main user (TNG master) must pull the changes from your repository:

cd location
git pull $HOME_OF_YOU$/myrepo master 

All changes are merged into the master branch. The TNG master must solve conflicts if they appear.

One can check what the other user did without trying to merge:

git fetch /home/bob/myrepo master
git log -p HEAD..FETCH_HEAD 

(show everything that is reachable from the FETCH_HEAD but exclude anything that is reachable from HEAD)

A visualization can be done using gitk or qgtk



                                                                     user commits changes 
                                                                     to temp. branches
               shared pulls                       user pulls          V
master repo ---------------------> shared repo --------------------> user repo
            <---------------------  ^                                 |
               master fetches       |                                 |
                                    |                                 | user  merges possible conflicts and
                                    |                                 | continues to work
                                    |                                 |
                                    |                                 V
                                    +------------------------------- user repo with
                                                  user pushes        committed changes

For shared (trusted) access to a repository a local clone of the master repo has been created which is marked as a shared repository.

In order to clone the shared repository, type

git clone  git clone user@servername:location myrepo my-project
cd my-project  


                       you push
 your personal repo ------------------> your public repo
   ^                                     |
   |                                     |
   | you pull                            | they pull
   |                                     |
   |                                     |
   |               they push             V
 their public repo <------------------- their repo

Users may fetch from this repo, but may not be able to push changes to it. The idea is that any developer has two repositories, a private and a public one. Then, the workflow is

In order to clone the public repository, type

git clone  git clone user@servername:location myrepo my-project
cd my-project

Creating the repositories

Creating a git repo

cd project-directory
git init 

Let git take a snapshot of the working dir:

git add . 

Now the contents is stored in a temporary staging area called "index"

git commit 

Remote repository

Define a remote repository (add user "bob"):

git remote add bob /home/bob/myrepo 

Using this, TNG master can fetch the changes without pulling:

git remote add bob /home/bob/myrepo  

The changes of bob are stored in an own branch ("bob/master") which can be reviewed. Let show the changes of bob

git log -p master..bob/master 

and merge them:

git merge bob/master  

Later, Bob can update his repo with the last changes of TNG master doing

git pull 


Assume that there is already a git repo existing, being located at


Create a new "bare" repository (a repository without a working tree) and fetch your project into it:

mkdir shared.git
cd shared.git
git --bare init --shared
git --bare fetch servername:location master:master 

Next, give every team member read/write access to this repository. One easy way to do this is to give all the team members ssh access to the machine where the repository is hosted. If you don't want to give them a full shell on the machine, there is a restricted shell which only allows users to do git pushes and pulls; see git-shell(1).

Put all the committers in the same group, and make the repository writable by that group:

chgrp -R tng shared.git 


  • Make sure committers have a umask of at most 027 (particularly Ubuntu/Mac), so that the directories they create are writable and searchable by other group members.
  • Developers who are allowed to have shared access, must be part of the same group. They have to clone the directory shared.git


The public repository was created via

git clone --bare SLangTNG public.git
touch public.git/git-daemon-export-ok

Anonymous HTTP

Install git-daemon Docu:


git clone --bar public.git tng_public
sudo cp -rf tng_public/ /srv/git/
rm -rf tng_public
chmod +x /srv/git/tng_public/hooks/post-update

After your nightly update, do:

git push /srv/git/tng_public

or to specify branches

git push /srv/git/tng_public mybranch:master

To enable the git:/ protocol,

touch /srv/git/tng_publicgit-daemon-export-ok

To enable the http protocol, link the repo to your www root.

Configure Git to interact with CVS

Please, use git directly and not the CVS emulator.

In order to set up your environment to commit using CVS, follow these steps:

  1. Check out the repository (CVS version > 1.12.11)
    cvs -d ":ext;CVS_SERVER=git cvsserver:user@server/path/repo.git" co \<HEAD_name>
  2. If you didn't specify the CVSROOT/CVS_SERVER directly in the checkout command, automatically saving it in your CVS/Root files, then you need to set them explicitly in your environment:
    export CVSROOT=:ext:user@server:/var/git/project.git
    export CVS_SERVER="git cvsserver"
  3. For SSH clients that will make commits, make sure their server-side .ssh/environment files (or .bashrc, etc., according to their specific shell) export appropriate values for
  4. Clients should now be able to check out the project. Use the CVS module name to indicate what GIT head you want to check out. This also sets the name of your newly checked-out directory, unless you tell it otherwise with -d <dir_name>. For example, this checks out master branch to the project-master directory:
cvs co -d project-master master
Information for users
Personal tools