Exim Development Using Git
The definitive exim git tree can be found at
Repository: https://code.exim.org/exim/exim.git
The main developers may push into this tree using their ssh access to
the development machine - the appropriate path is
ssh://git@code.exim.org/exim/exim.git - the developer will need to
have previously been added to the exim-developers team.
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 https://code.exim.org/exim/
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 http://git.exim.org/ after a short interval, and may be accessed by others.
Those without write access to the development system can use alternative git hosting solutions such as forgejo under codeberg.
Github
The repositories previously hosted on GitHub are not longer updated and will be archived in due course.
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 codeberg 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....
-
Initially set your repository up using
git clone https://code.exim.org/exim/exim.git -
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 configcommand with keysuser.nameanduser.email -
Ensure that the development machine has a
public_gitsubdirectory of your home directory. Create an empty git repository within that directory -cd ~/public_git; git init --bare myrepo.git -
Set a new remote pointing to a new repo into your
public_gitsubdirectory - iegit add mydef ssh://git.exim.org/home/nm4/public_git/myrepo.git -
Set up a second remote pointing to the main repository - ie
git add mainline ssh://git.exim.org/home/git/exim.git
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.