Skip to content
Nigel Metheringham edited this page Nov 25, 2012 · 1 revision

Exim Development Using Git

The definitive exim git tree can be found at git:// with a web view available at

The main developers may push into this tree using their ssh access to the development machine - the appropriate path is ssh:// - the developer will need to be a member of the eximdev group.

Repository Scope

The single development repository contains:-

  • The exim source including bundled utilities
  • The exim documentation source
  • The test suite
  • Scripts required as part of the release process

The web site and other ancillary data is not contained in the main repository, but will normally be in other repositories under

Enforcement and Checking Hooks

These hooks have not been implemented at this point, however it is intended that the following policies will be enforced on pushes to the repository - and we will also have an appropriate script so this can be added to your local repositories.

  • No tabs (only spaces) other than where necessary (ie Makefiles )
  • No trailing spaces (local fix you can use)
  • No version tags from other VCS systems - ie $Id$ or $Cambridge$

A hook which triggers on push to the main repo will also parse BugZilla related state commands in commit comments.

Other Repositories

Those with access to the development system can push repositories into the public_git subdirectory of their home directory - these directories will become visible on after a short interval, and may be accessed by others.

Those without access to the development system can use alternative git hosting solutions (such as github or Indefero) or their own hosting.


There is also a repository at github in the Exim Organisation - the repository is at

At present the canonical repository is on - synchronisation with the github repo is a manual process. We will refine the github integration as we get time.

Development Process

  • Development branches are kept local and not pushed into the main repository, however they may be pushed into publicly available repositories for others to inspect
  • Those with commit access to the main repository may push directly onto the master branch
  • Others will need to make their changes visible to one of the committers and convince them to merge and push their changes. It may be appropriate to use a hosted git environment such as github or Indefero to make changes available to others, although requests on the exim-dev mailing list and/or BugZilla entries can be used to make developers aware of changes.
  • Reviewing changes before pushing to the main repository is very very strongly encouraged
  • Changes should include relevant documentation changes, and it is strongly suggested that code changes are checked using the test suite.

Technical Setup

Others may disagree on this - this is my suggested setup as someone who has full commit access....

  1. Initially set your repository up using git clone git://

  2. Ensure that your name and email address are set correctly (especially if the exim development email address you use is different to your default one - use git config command with keys and

  3. Ensure that the development machine has a public_git subdirectory of your home directory. Create an empty git repository within that directory - cd ~/public_git; git init --bare myrepo.git

  4. Set a new remote pointing to a new repo into your public_git subdirectory - ie git add mydef ssh://

  5. Set up a second remote pointing to the main repository - ie git add mainline ssh://

This allows you to pull easily from the mainline using a git pull command. You can push either to your own visible respository, or to the main repository as appropriate.

Sample Workflows

There are always various ways to use git with regard to workflow, but here are examples of common tasks.