Systems - GIT Repository / Development Workflow

This page describes typical workflows using Git CAcerts new version control system of choice. See also Software/WorkingWithGit, which should say similar things as this article here...

Software/Assessment/Documentation ist the current practice document.

This is work in progress


Where to get Git

Git is available for all major platforms, you can get it either through the package repositories of your Linux distribution of choice (packages git-core, git-doc and for some helpful GUI tools gitk, git-gui in Debian/Ubuntu) or from the Git website


CAcert on Github

Doco on Git for the newcomer:

Basic Configuration

Before you start using Git for the first time you should do some configuration. Most importantly you need to tell Git your name and email address which shows up in the commit messages:

git config --global "Alice Smith"
git config --global

Also you probably want to set your favourite editor to edit commit messages and the like (this doesn't have to be the one you want to edit the code with, I personally prefer a non-GUI one for this purpose):

git config --global core.editor nano

Git can produce coloured output e.g. for diffs which can be helpful to keep the overview. You can turn it on by executing

git config --global color.ui auto

If you want to use the Git GUI (I personally use it for staging and commits) then you will notice that the translation is not very helpful so you might want to switch to the English version:

  1. First you have to find out how your $LANG variable is set:

    echo $LANG
  2. On my system it's de_DE.UTF-8 now you replace the lower case letter pair with en and the upper case one with US, so for my system it's en_US.UTF-8

  3. Now add an alias command to your system by executing (replacing en_US.UTF-8 by the language string fo your system as determined in the previous step)

    echo "alias gg='LANG=en_US.UTF-8 git gui'" >> ~/.bashrc
  4. Now you can use the shorthand gg whenever you would normally use git gui to get the English variant


Get the Source Code

Change into the directory where you want the source to be checked out (Git will create a new directory) and execute (replacing <directoryname> with the name of the directory Git should create):

git clone git://<reponame> <directoryname>

There are several repositories, which hold several versions of the code:

The choice is yours, grab the official code or review/work on already imported patches.

Make your changes

Once you cloned your working copy, you can start reviewing the code or setup an web server to build your own testing environment. There will be a VMWare image download shortly, which contains an testing environment built by the CACert Production Systems Administrators. Stay tuned.

If you just review the code, please submit a bug message to our mantis bug tracking system located here If you want to help by adding patches, please make sure you have had a close look into mantis. There are quite some bugs to fix, just in case you need some work *G*. Grab the bug, add your comments.

Once you developed an patch or improvement, you should test your code as far as you can.

As all git repositories are read only (currently, if there is demand, we will think about opening one repo for writing), you need a way to deliver the patch to CACert. There are, as always, more than one possible solutions:

  1. your git working copy already is a full grown git repository, you can share it by installing git-daemon and just put the "link" to your patch into the mantis bug. A software assessor will then pull the patch from your repository, review the code and merge it into the cacert-devel repository.
  2. prepare your patch by using the git format-patch command and send it to an software assessor, please ask before you send tons of code, the person owning the mailbox might be busy and unable to process your patch in an appropriate time!
  3. make diff files and attach the diffs to the mantis bug
  4. ...

In either case, once the code is in the cacert-devel repository, CACert will start official testing runs on Usually several issues will be bundled and tested within one cycle. After the patches have been signed off, code will be forwarded to the Release Manager who will promote the code to the production system.

Please note that this is WiP, if you think you need more means to submit patches, please stand up and speak. Same for all other aspects of the process.

Commands to make the patch, to add a new file and to adjust from an old one


Software Assessors

Fetch & Merge current official tarball to cacert-devel

Right now the process is under development, thus parts of the old procedures are still in use. This includes the generation and publication of a new tarball containing the whole source code, once a change to the webdb code was put live. We need to get this code and merge it to the devel repository to be sure that all changes which are made NOT through the new process using git nevertheless make it into our git development repository. Here is how it works:

  1. git clone ssh:// cacert

  2. git clone ssh:// cacert-devel

  3. get tarball and extract into cacert working copy
    1. fetch the tar file from

    2. cd cacert
    3. rm -r ./*
    4. tar -xj --strip=1 -f <nameoftarball>

    5. git status
    6. restore eventually deleted .gitignore files (marked as deleted): i.e. git checkout includes/.gitignore
    7. git add <new files> # add new files

    8. git commit -a # automatically handles modifies and deletes, but NOT new files
    9. git push
  4. merge changes with cacert-devel, can be done the easy or (little) hard way
    1. git remote add cacertlive git://
    2. easy way: git pull cacertlive master # this is the easy way, just merge automatically, no manual intervention
    3. hard(er) way: use git fetch, git checkout/diff and git merge to examine diffs
    4. git log origin/master..master # see local commits vs. origin repository
    5. git diff <ref>..<ref> # display file by file diffs between refs # you can examine changes even when using pull

  5. git push

How to reset the testserver to a defined state ?

How to update your local copy to the lastest revision from central repository ?

More details on working with Git


git URI


proposed local path





mirror of current live webdb state, should be the same tarball as under download link




current development branch




Testserver Mgmt System repository current state




Birdshack repo (was on .cl)




moved Boardvoting repo from .cl




RoundCube CRT Auth

Getting commit access

Contact Markus with NAME (your unix/ssh style username) and SSH public key. Once installed, try this:

(change the CAPS parts) This brings you your own personal repository, cloned form the master. To send your committed changes up to the master, do



This is the new GIT repository for Software-Assessment and Developers

Physical Location

This system is an etch ? lenny ? vm on (ESX)

Logical location

Applicable Documentation

This is it :-)


System Admin:


Listening services

Running services

Connected Systems

Outbound network connections


Non-distribution packages and modifications

Risk assessments on critical packages


Critical Configuration items

Apache config



System Future

Document Stuff

Software/DevelopmentWorkflow (last edited 2021-08-18 08:09:33 by BernhardFröhlich)